Friday, 12 February 2016

Re: Archive Reorg Episode VII: Follow Build-Depends

Steve Langasek [2016-02-11 20:29 -0800]:
> There is a third option here, which I discussed with Colin and Adam and that
> (I think) we agree is workable: enable inclusion of universe in the image
> builds during development, turning this off only once we are in the final
> freeze for release.

A big and strong NACK from my side. 10 years of experience in doing
releases have shown that this just plain doesn't work. In the end the
release team is forced to force-push all the universe stragglers to
main against our better judgement, as really nobody outside the
release team cares and right before a release there's no practical way
to revert/drop the features or new packages that caused this.

This would encourage the "throw it over the fence and make fixing it
an SEP" behaviour happen even more often. This isn't really meant to
be a personal blame to anyone -- people do what they get rewarded for,
and developers of new features or uploaders of new package versions
usually don't get rewarded (or even get time allocated) for fixing
issues like this unless they aren't able to land their feature.

Please let's keep the responsibility where it belongs.

Sorry for the strong words, but if we do this we can just as well stop
having a main/universe split completely. If that's the desire, then
let's rather be honest about it.

> This has the important properties of keeping velocity high for image daily
> builds (no build failures due to component-mismatches in the devel series,
> and no human intervention required to promote a package to un-break a
> build), while ensuring that we are still able to track the list of
> outstanding issues for release in a well-visible report.

Track yes, but honestly, who will end up acting on it?

> Well, first of all, the problem you're describing doesn't sound to me like
> some future dystopia... it sounds to me like the current complaints about
> the MIR process, with the owning teams not being reliable at taking
> responsibility for their new packages and leaving the MIR team to drive
> this.

So how is enabling universe for image builds helping here? If the MIR
team isn't able to process the new MIRs for a release in several
months, how are they going to do it in a week?

> Thirdly, it should be noted that a 35% reduction of source packages in main
> (Dimitri's current best estimate) does not translate to a 35% reduction in
> MIRs. My guess is that the reduction in MIRs will be *greater* than 35%
> compared to the current volume

Agreed to that, yes.

> And fourthly :-), please note that at a technical and process level, this
> latest proposal is almost entirely equivalent to the previous proposal for
> archive reorganization. That proposal foundered mainly because of the
> difficulties about communicating to our users that "main" no longer means
> "supported by Canonical".

That indeed, I rather consider it as something like "reviewed and
accepted by the Ubuntu project as a sustainable technology" stamp. E.
g. to make sure that we don't use fifty different unsupportable
JavaScript engines or three outdated Qt APIs, but instead have some
pressure to port things to the ONE API/technology we select and
prefer. This not only makes maintenance and security support easier,
but also helps against unbound image growth and an ever-growing pile
of cruft that users have to install and update. This has created
quite a large technical debt over time which is now slowing down
development at least as much as new MIRs (examples: gst 0.10, GTK 2,
Qt 4, Python 2, udisks 1.x, old gccs).

This already got a lot worse with the beginnings of the archive reorg,
but at least the effect is still noticeable for the Ubuntu flavor that
builds out of main.

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

--
ubuntu-devel mailing list
[email protected]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel