Bug#769673: RFS: lletters/0.1.95+gtk2-4 [ITA, RC]
Hi Dmitry,
On Sun, Jan 4, 2015 at 7:38 PM, Dmitry Borisyuk <q1werty@i.com.ua> wrote:
> Dear Vincent,
>
> Thanks for your review.
>
> The purpose of debian/patches/debian-changes-0.1.95+gtk2-3.2.patch
> was to switch to source format 3.0 (quilt). It contains the changes
> between the upstream and Debian version 3.2. Many files were changed,
> not just autoconf-related ones, so I need this patch to incorporate those changes.
I no longer have your package on hand, nor can I find it on
mentors.d.n, so I can't discuss any specifics, but IIRC that giant
patch shouldn't have been necessary if you were going to run
autoreconf at some point during the build.
> Why use 3.0 (quilt)? Beacuse some sponsors insist on it, so I thought it's somewhat like mandatory... If you prefer source format 1.0, this patch is not needed, of course.
I myself prefer 3.0 (quilt) as source format as well...the reason
being that it encourages maintainers to use a common workflow and also
encourages changes to the source code to be represented as a set of
self-contained, easily reviewable patches. However, it is still
possible to abuse 3.0 (quilt) and make patches difficult to review
simply by just providing a single giant patch (e.g. by making a bunch
of unrelated changes to the source package, then running dpkg-source
--commit). I'm not saying that's what you did, just wanted to
emphasize the fact that sponsors don't usually insist on something
just because it's mandatory (3.0 (quilt) is not mandatory, by the
way), but because it directly or indirectly leads to the package being
easier to review and maintain.
FWIW, my sponsoring approach usually involves reading the debdiff (to
the last upload), and the most off-putting thing for me to review is
something with a massive diff; I'm sure the release team can attest to
that as well.
> There are some other patches, which are not strictly needed, but I thought they improve the package, I could explain in detail if you wish.
You're more than welcome to upload a new package to mentors.d.n if
you'd still like to adopt lletters, and we can go from there. :)
> Yes, I could adopt lletters-media if this is a precondition for adopting lletters. I'm not familiar with what team-maintaining is,
> at a glance it seems that lletters is not well suited for Games team.
It's not mandatory for you to adopt lletters-media, but as it is a
dependency of lletters (and the two source packages come from the same
upstream anyways), I would strongly recommend doing so; e.g. if
lletters-media ever gets removed due to a RC bug, lletters will also
be removed, and the best way to prevent that is to adopt the former
package and ensure that never happens.
Team maintenance is up to you, but I generally encourage it as well
because it allows for a group of maintainers to collaborate together
on the same set of packages, and it's also easier for you to seek
sponsorship or just general help with your package if you're
co-maintaining a package or maintaining it in a team. Just curious,
why do you think lletters is not suitable for team maintenance under
the Games team?
Regards,
Vincent
Reply to: