Re: Bits from the Release Team: ride like the wind, Bullseye!

[Niels Thykier <niels@thykier.net>]

Vincent Bernat:
>  ❦  7 juillet 2019 02:47 +01, Jonathan Wiltshire <jmw@debian.org>:
> 
>> No binary maintainer uploads for bullseye
>> =========================================
>>
>> The release of buster also means the bullseye release cycle is about to begin.
>> From now on, we will no longer allow binaries uploaded by maintainers to
>> migrate to testing. This means that you will need to do source-only uploads if
>> you want them to reach bullseye.
>>
>>
>>   Q: I already did a binary upload, do I need to do a new (source-only) upload?
>>   A: Yes (preferably with other changes, not just a version bump).
>>
>>   Q: I needed to do a binary upload because my upload went to the NEW queue,
>>      do I need to do a new (source-only) upload for it to reach bullseye?
>>   A: Yes. We also suggest going through NEW in experimental instead of unstable
>>      where possible, to avoid disruption in unstable.
> 
> I didn't follow carefully the past discussion, but why aren't we just
> throwing the uploaded binaries away?
> 

Hi Vincent,

I supported this method because it:

 * reliably catches all maintainer-built packages in main.

   Some maintainers will still need to bootstrapping in unstable using
   maintainer-built binaries due to  the complexity of their packages.
   This method will simply stop them in sid until they have been
   rebuilt on the buildds.  Compare with throw-away binaries, where
   exceptions are not easily tracked out of the box (plus you would need
   to implement an exception workflow too).

 * was simple and fast to deploy.

   It required a trivial policy in Britney plus some code to fetch data
   and it just works.  Compare here with throw-away binaries, where the
   ftp-masters would have to implement changes to dak to support this
   and accommodate for the complexity of binary-bootstrapping.

 * can be combined with throw-away binaries at a later point.

   If/when we implement a good solution to throw-away, we can deploy
   that next to this change.  As mentioned in past points, there are
   cases where we would still need maintainer-built binaries
   temporarily, so we would still need a solution like this to ensure
   full coverage.

I hope this answered your question to satisfaction.

Thanks,
~Niels