Hi Dmitry, On Sun, Jan 4, 2015 at 7:38 PM, Dmitry Borisyuk <q1we...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
