LSB Ubuntu merge (was Re: Bug#673586: FTBFS if Python 3.2 is installed in chroot)
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
Reply to: