Saturday 19 March 2016

Re: Archive Reorg Episode VII: Follow Build-Depends

On 19.03.2016 05:48, Steve Langasek wrote:
> Hi all,
>
> On Fri, Feb 12, 2016 at 04:03:37PM +0100, Martin Pitt wrote:
>> 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.
>
> FWIW I don't agree; we already have component-mismatches which we have a
> committment to drive to zero for release, and the teams that have introduced
> the new dependencies are responsible for driving the MIRs for those
> packages. So I believe that we would be no worse off by letting images
> build with universe enabled than we are today, since
> components-mismatches-zero is already a requirement for release and we would
> be reducing the overall workload related to this.

Looking at reality, being responsible and doing this work in a timely manner
such that it doesn't end up on another's one plate are two different things.
Implementing this technical archive change doesn't improve this situation, I
fear things get delayed even more. But that's something which has to be
addressed on an organizational level.

Matthias


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel