Hi again Steve, Le dimanche, 19 mai 2013 03.44:04, Steve Langasek a écrit : > On Wed, May 15, 2013 at 11:31:03PM +0200, Didier 'OdyX' Raboud wrote: > > I feel compelled to point out here that this is not how I understand > > collab- maint is supposed to work. That said, in that case, despite > > preferring commit messages not including debian/changelog messages in > > favour of git-dch, I'm happy with your commits that I had already > > committed (but not pushed) :) > > Whoops, sorry for the misunderstanding. I guess there isn't a consistent > view of what "collab-maint" means; I always understood it as meaning that > any developer could always commit fixes there
My understanding (and AFAIK confirmed by the wiki documentation) of collab- maint is that it's a "low-overhead collaborative maintenance" alioth project: if you only need a VCS to share code with others, collab-maint provides you that. My understanding is also that co-maintenance rules still apply (aka co- maintainers can commit, the others are expected to ask first). > Would it be ok if I pushed any future changes to a separate branch in git > for your consideration? Or do you prefer that I send all patches by mail? As you might have seen, I try to always attribute the changes as single commits to the original uploaders (very often it's been from Ubuntu, so taking the commit message and uploader name+email for the commit. When I've been nitpicking, also the time), and not altering the debian/changelog that I prefer to generate and hand-beautify at release time. The easiest is the probably the separate branch, from which I can cherry-pick / amend from. But I'm fine with any low-overhead workflow that suits you best (nah, not bzr though. :-} ) > BTW, I just noticed that the source package for +Debian11 contains the > source tarball for +Debian10... oops ;) Yeah. Colin Watson made me aware of that already, *sigh*. > > > The remaining delta consists of a few pieces: > > > - The actual switch to python3. (…) > > I don't have a very clear vision yet on the impact of such a change on > > the rest of Debian (d-i and default installation footprint come to mind) > > as lsb- release will pull in python3 in quite a lot of situations. I > > will therefore branch the code and upload the work-in-progress in that > > direction to experimental. > > Ok. For the record, d-i is universally python-averse, so it doesn't matter > if it's python2 or python3, lsb-release is definitely not included in d-i. Indeed. I should have written "debian-cd and in particular CD#1" instead of d- i. > Also, while python is Priority: standard, both python3 and lsb-release are > Priority: optional. It should probably be discussed with the wider Debian > Python community what the plans are here for jessie, but I *suspect* it > will be reasonable to flip these two, especially as it appears the only > Prio: standard packages using python are apt-listchanges and reportbug. I'll certainly launch that discussion once a full python3-powered src:lsb got uploaded in experimental. > > > Oh, fwiw, I have to say I'm not a fan of the derived_from_ubuntu logic > > > in the Debian package. I think it's vastly preferable to keep such > > > differences as source package deltas than to have the same source > > > package give different results when built on different derivatives. > > > > Well; having all changes happen on the same codebase (and VCS) IMHO helps > > avoiding useful distribution-agnostic changes in derivatives as > > contributors are compelled to think twice whether the change is agnostic > > or specific afterall. > > I don't think this has the effect you hope for. Unless the person making > the change in the derivative also has commit access to the Debian VCS, That's the case I was referring to: someone from a $derivative committing things directly in the Debian VCS and generating his $derivative-specific source package from there. > there will always be a tension between trying to do things "upstream > first" and answering to the demands of the downstream release schedule. > > So even getting lsb in sync in Ubuntu is no guarantee that it will stay in > sync. Surely not; but if, say, Ubuntu developers maintaining src:lsb were handling the source package directly from the Debian VCS (eventually in *ubuntu* branches), then (again, as I see it) there would be less friction (and work) for the integration of $distro-specific changes back to Debian. That's my ideal world vision, but I'm fully ready to admit that I'm probably neglecting how easy the bzr-launchpad pair is to use when developing for Ubuntu. Cheers, OdyX -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
