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

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Holger Levsen-2
Hi,

On Sun, Jul 07, 2019 at 02:47:00AM +0100, Jonathan Wiltshire wrote:
> Shortly before the end of the 6th July, we released Debian 10, "buster".

*yay* *yay* & *yay*!

> 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.
whoooohoooo, that's *totally* awesome news! loving it.

> All autopkgtest failures considered RC for bullseye

also very yay!

exciting times ahead!


--
tschau,
        Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Lisandro Damián Nicanor Pérez Meyer-2
Hi!

[snip with a huge yay!]

> All autopkgtest failures considered RC for bullseye
> ===================================================
>
> From now on, all autopkgtest failures will be considered release-critical for
> bullseye. So if your package has failing autopkgtests, now is a good time to
> start looking for a fix

Now this raises some questions for me. Now I maintain a (huge) library
(hello Qt!). I do an unstable upload and package A starts failing it's
autopkgtests. In this case:

- How does this failure affects the uploaded library (imagine we have
a transition, as it will always be Qt's case due to private headers).
- What's expected from the maintainers of the library?

Thanks, Lisandro.

Reply | Threaded
Open this post in threaded view
|

Re: mandatory source uploads (was: Bits from the Release Team: ride like the wind, Bullseye!)

Thomas Goirand-3
In reply to this post by Holger Levsen-2
On 7/7/19 3:16 PM, Holger Levsen wrote:

> Hi,
>
> On Sun, Jul 07, 2019 at 02:47:00AM +0100, Jonathan Wiltshire wrote:
>> Shortly before the end of the 6th July, we released Debian 10, "buster".
>
> *yay* *yay* & *yay*!
>
>> 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.
>
> whoooohoooo, that's *totally* awesome news! loving it.

I don't. I don't fee happy of this at all, and here's why.

I have 150 OpenStack packages waiting in Experimental, built for the
OpenStack Stein release. OF COURSE, they all are inter-dependent, and to
build a given package, you probably need the latest version of another one.

So, instead of preparing them all (build them all for Unstable and
upload at once, using sbuild and --extra-package when needed), it means
that I'll have to build them one by one, upload, wait for the next dak
run to have a new package in, then go to the next. With the amount of
package, this probably can take 3 weeks to a month instead of a single
week like I planned.

Also, the result, it's *less nice* for Sid/Bullseye users, because the
transition will be super long if I do this way.

The other alternative is to build all like I planned, upload all to
Unstable, then rebuild all again, and do a 2nd upload (source only this
time). There, I'm also loosing a lot of time for no valid technical
reason, which isn't nice at all either. I feel like I'm going to be
doing all of this during all of debcamp / debconf, which isn't fun at
all, I had planned for other stuffs to do there.

Advice on what's the best way would be welcome.

I also very much would prefer if this wasn't announced just like this,
without giving any amount of time to prepare for the thing and discuss
it. That's not the first time the release team does this way, and that's
really not the best way to do things. (If I missed the discussion, then
IMO it wasn't advertised enough, which has the same effect.)

I very much salute the source-only enforcement, but I really don't think
this was thought through completely.

Cheers,

Thomas Goirand (zigo)

Reply | Threaded
Open this post in threaded view
|

Re: mandatory source uploads (was: Bits from the Release Team: ride like the wind, Bullseye!)

Scott Kitterman-5
On Sunday, July 7, 2019 6:30:58 PM EDT Thomas Goirand wrote:

> On 7/7/19 3:16 PM, Holger Levsen wrote:
> > Hi,
> >
> > On Sun, Jul 07, 2019 at 02:47:00AM +0100, Jonathan Wiltshire wrote:
> >> Shortly before the end of the 6th July, we released Debian 10, "buster".
> >
> > *yay* *yay* & *yay*!
> >
> >> 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.
> >
> > whoooohoooo, that's *totally* awesome news! loving it.
>
> I don't. I don't fee happy of this at all, and here's why.
>
> I have 150 OpenStack packages waiting in Experimental, built for the
> OpenStack Stein release. OF COURSE, they all are inter-dependent, and to
> build a given package, you probably need the latest version of another one.
>
> So, instead of preparing them all (build them all for Unstable and
> upload at once, using sbuild and --extra-package when needed), it means
> that I'll have to build them one by one, upload, wait for the next dak
> run to have a new package in, then go to the next. With the amount of
> package, this probably can take 3 weeks to a month instead of a single
> week like I planned.
>
> Also, the result, it's *less nice* for Sid/Bullseye users, because the
> transition will be super long if I do this way.
>
> The other alternative is to build all like I planned, upload all to
> Unstable, then rebuild all again, and do a 2nd upload (source only this
> time). There, I'm also loosing a lot of time for no valid technical
> reason, which isn't nice at all either. I feel like I'm going to be
> doing all of this during all of debcamp / debconf, which isn't fun at
> all, I had planned for other stuffs to do there.
>
> Advice on what's the best way would be welcome.
>
> I also very much would prefer if this wasn't announced just like this,
> without giving any amount of time to prepare for the thing and discuss
> it. That's not the first time the release team does this way, and that's
> really not the best way to do things. (If I missed the discussion, then
> IMO it wasn't advertised enough, which has the same effect.)
>
> I very much salute the source-only enforcement, but I really don't think
> this was thought through completely.

As long as your build-depends are properly versioned, why can't you just
upload all the source and let wanna-build sort it out?

Scott K



Reply | Threaded
Open this post in threaded view
|

Re: mandatory source uploads

Philipp Kern-6
On 2019-07-08 00:34, Scott Kitterman wrote:

> On Sunday, July 7, 2019 6:30:58 PM EDT Thomas Goirand wrote:
>> On 7/7/19 3:16 PM, Holger Levsen wrote:
>> > Hi,
>> >
>> > On Sun, Jul 07, 2019 at 02:47:00AM +0100, Jonathan Wiltshire wrote:
>> >> Shortly before the end of the 6th July, we released Debian 10, "buster".
>> >
>> > *yay* *yay* & *yay*!
>> >
>> >> 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.
>> >
>> > whoooohoooo, that's *totally* awesome news! loving it.
>>
>> I don't. I don't fee happy of this at all, and here's why.
>>
>> I have 150 OpenStack packages waiting in Experimental, built for the
>> OpenStack Stein release. OF COURSE, they all are inter-dependent, and
>> to
>> build a given package, you probably need the latest version of another
>> one.
>>
>> So, instead of preparing them all (build them all for Unstable and
>> upload at once, using sbuild and --extra-package when needed), it
>> means
>> that I'll have to build them one by one, upload, wait for the next dak
>> run to have a new package in, then go to the next. With the amount of
>> package, this probably can take 3 weeks to a month instead of a single
>> week like I planned.
>>
>> Also, the result, it's *less nice* for Sid/Bullseye users, because the
>> transition will be super long if I do this way.
>>
>> The other alternative is to build all like I planned, upload all to
>> Unstable, then rebuild all again, and do a 2nd upload (source only
>> this
>> time). There, I'm also loosing a lot of time for no valid technical
>> reason, which isn't nice at all either. I feel like I'm going to be
>> doing all of this during all of debcamp / debconf, which isn't fun at
>> all, I had planned for other stuffs to do there.
>>
>> Advice on what's the best way would be welcome.
>>
>> I also very much would prefer if this wasn't announced just like this,
>> without giving any amount of time to prepare for the thing and discuss
>> it. That's not the first time the release team does this way, and
>> that's
>> really not the best way to do things. (If I missed the discussion,
>> then
>> IMO it wasn't advertised enough, which has the same effect.)
>>
>> I very much salute the source-only enforcement, but I really don't
>> think
>> this was thought through completely.
>
> As long as your build-depends are properly versioned, why can't you
> just
> upload all the source and let wanna-build sort it out?

That'd assume that there are no circular dependencies. I take it that
they are all arch:all? (Because otherwise wanna-build would already need
to figure it out for you to build on other architectures.)

Kind regards
Philipp Kern

Reply | Threaded
Open this post in threaded view
|

Re: mandatory source uploads (was: Bits from the Release Team: ride like the wind, Bullseye!)

Thomas Goirand-3
In reply to this post by Scott Kitterman-5
On 7/8/19 12:34 AM, Scott Kitterman wrote:
> As long as your build-depends are properly versioned, why can't you just
> upload all the source and let wanna-build sort it out?
>
> Scott K

This means that I have to baby-sit the Debian archive and upload
everything in the correct order, waiting for the previous upload to be
accepted and online.

BTW, one very important thing: are the buildds configured to use
incoming at least? If so, that probably could be bearable.

> That'd assume that there are no circular dependencies.

On 7/8/19 8:27 AM, Philipp Kern wrote:
The very small amount of circular (build-)dependency is probably not the
issue, as using the older version should be fine. The thing I'm
expecting is build failure with non-matching versions (OpenStack
upstream CI is built to work with everything from the same release).

> I take it that
> they are all arch:all? (Because otherwise wanna-build would already
> need to figure it out for you to build on other architectures.)

Most (if not all) is in Python, so yes, arch:all.

Cheers,

Thomas Goirand (zigo)

Reply | Threaded
Open this post in threaded view
|

Re: mandatory source uploads

Philipp Kern-6
On 2019-07-08 09:14, Thomas Goirand wrote:
> On 7/8/19 12:34 AM, Scott Kitterman wrote:
>> As long as your build-depends are properly versioned, why can't you
>> just
>> upload all the source and let wanna-build sort it out?
[...]
> This means that I have to baby-sit the Debian archive and upload
> everything in the correct order, waiting for the previous upload to be
> accepted and online.

Not really. wanna-build will only schedule the build if the build
dependency is satisfiable. So if you encode everything correctly there
(which might be hard, c.f. circular build dependencies), wanna-build
will schedule in the correct order by itself.

> BTW, one very important thing: are the buildds configured to use
> incoming at least? If so, that probably could be bearable.

And of course buildds use incoming and so does wanna-build.

Kind regards
Philipp Kern

Reply | Threaded
Open this post in threaded view
|

Re: mandatory source uploads

Thomas Goirand-3
On 7/8/19 9:38 AM, Philipp Kern wrote:

> On 2019-07-08 09:14, Thomas Goirand wrote:
>> On 7/8/19 12:34 AM, Scott Kitterman wrote:
>>> As long as your build-depends are properly versioned, why can't you just
>>> upload all the source and let wanna-build sort it out?
> [...]
>> This means that I have to baby-sit the Debian archive and upload
>> everything in the correct order, waiting for the previous upload to be
>> accepted and online.
>
> Not really. wanna-build will only schedule the build if the build
> dependency is satisfiable. So if you encode everything correctly there
> (which might be hard, c.f. circular build dependencies), wanna-build
> will schedule in the correct order by itself.
>
>> BTW, one very important thing: are the buildds configured to use
>> incoming at least? If so, that probably could be bearable.
>
> And of course buildds use incoming and so does wanna-build.
>
> Kind regards
> Philipp Kern

Thanks Philipp, for the advice.

So if I understand correctly, I can just rebuild everything and do
source-only uploads, and the Debian infra will be smart enough to
understand how to build? Great, I'll try then! :)

Cheers,

Thomas Goirand (zigo)

Reply | Threaded
Open this post in threaded view
|

Re: mandatory source uploads

Samuel Thibault-8
Thomas Goirand, le lun. 08 juil. 2019 11:57:45 +0200, a ecrit:
> So if I understand correctly, I can just rebuild everything and do
> source-only uploads, and the Debian infra will be smart enough to
> understand how to build?

Yes.
Only the dependency loops pose problem.

Samuel

Reply | Threaded
Open this post in threaded view
|

Re: mandatory source uploads (was: Bits from the Release Team: ride like the wind, Bullseye!)

Matthias Klumpp-2
In reply to this post by Thomas Goirand-3
Am Mo., 8. Juli 2019 um 09:14 Uhr schrieb Thomas Goirand <[hidden email]>:

>
> On 7/8/19 12:34 AM, Scott Kitterman wrote:
> > As long as your build-depends are properly versioned, why can't you just
> > upload all the source and let wanna-build sort it out?
> >
> > Scott K
>
> This means that I have to baby-sit the Debian archive and upload
> everything in the correct order, waiting for the previous upload to be
> accepted and online.

But why? If the build dependencies are tightened enough so that builds
are run in order anyway, this issue shouldn't occur. If a dependency
isn't built in the correct version yet, the package will just wait
with its build until the dependency does become available.

> BTW, one very important thing: are the buildds configured to use
> incoming at least? If so, that probably could be bearable.

AFAIK they indeed do that.

> [....]

Cheers,
    Matthias

--
I welcome VSRE emails. See http://vsre.info/

Reply | Threaded
Open this post in threaded view
|

Re: mandatory source uploads

Johannes Schauer-3
In reply to this post by Samuel Thibault-8
Quoting Samuel Thibault (2019-07-08 12:01:01)
> Thomas Goirand, le lun. 08 juil. 2019 11:57:45 +0200, a ecrit:
> > So if I understand correctly, I can just rebuild everything and do
> > source-only uploads, and the Debian infra will be smart enough to
> > understand how to build?
> Yes.  Only the dependency loops pose problem.

wanna-build is currently not able to break build dependency cycles by itself
even if build profile annotation (i.e <!stage1> or similar) would theoretically
allow it to do so.

Maybe this is a good time to either:

 - teach wanna-build how to schedule profile built binary packages (which will
   *not* end up in the archive) to break dependency cycles

 - allow developers to annotate uploads with a specific build profile that the
   source package is supposed to be built with (maybe in the .changes file?) --
   again the result should not end up in unstable but be used to break
   dependency cycles with hard version constraints

Thanks!

cheers, josch

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: mandatory source uploads

gregor herrmann-3
In reply to this post by Thomas Goirand-3
On Mon, 08 Jul 2019 11:57:45 +0200, Thomas Goirand wrote:

> So if I understand correctly, I can just rebuild everything and do
> source-only uploads, and the Debian infra will be smart enough to
> understand how to build? Great, I'll try then! :)

As long as you don't hit #865304 (taken from /topic in #debian-ftp)
or some of the other similar bugs which affect arch:all (?) uploads;
then dak moves package to NEW which are simply waiting for their
dependencies to be built.

(Sorry if this is a bit vague, I don't remember the exact details but
there is a well-known problem in this area.)


Cheers,
gregor

--
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-  

signature.asc (981 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Matthias Klose
In reply to this post by Holger Levsen-2
> 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 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 think this is bad advice, because with long running builds, you'll get stuck
in NEW twice, once doing the upload in experimental, and then doing the source
only upload to unstable, because your binary packages got already removed, and
the builds from the buildds land in NEW again.  So if you want to enforce that,
it would be better to avoid that extra work on the FTP team, and the package
uploaders.

Matthias

Reply | Threaded
Open this post in threaded view
|

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

Marco d'Itri
In reply to this post by Holger Levsen-2
On Jul 07, Jonathan Wiltshire <[hidden email]> wrote:

>   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).
Is there any good reason why we still do not have an interface to allow
developers to self-service request a binNMU of a package?
It would solve this and other problems.

--
ciao,
Marco

signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Adam Borowski-3
On Tue, Jul 09, 2019 at 12:16:53AM +0200, Marco d'Itri wrote:
> On Jul 07, Jonathan Wiltshire <[hidden email]> wrote:
>
> >   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).
> Is there any good reason why we still do not have an interface to allow
> developers to self-service request a binNMU of a package?
> It would solve this and other problems.

Main reason being trying to get rid of binNMUs, to be replaced by
changelog-only source uploads (for a number of reasons, such as not working
on arch:all packages, fragile wrt dependencies, breaking multiarch when
every arch is not in sync, requiring tricky tracking of rebuilds --
especially for archs in a different wanna-build such as -ports, especially
tricky tracking for unofficial ports, etc).

There's no convenient tooling for sourceful "bin"NMUs yet, but the
maintainer can already do that by hand.


Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ According to recent spams, "all my email accounts are owned
⢿⡄⠘⠷⠚⠋  by a hacker".  So what's the problem?
⠈⠳⣄⠀⠀⠀⠀

Reply | Threaded
Open this post in threaded view
|

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

Sean Whitton
In reply to this post by Marco d'Itri
Hello,

On Tue 09 Jul 2019 at 12:16AM +02, Marco d'Itri wrote:

> On Jul 07, Jonathan Wiltshire <[hidden email]> wrote:
>
>>   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).
> Is there any good reason why we still do not have an interface to allow
> developers to self-service request a binNMU of a package?
> It would solve this and other problems.

My impression from talking to wanna-build people is that there are
sufficiently many subtleties involved in correctly scheduling binNMUs
that costly (in terms of buildd and human time) mistakes would be
likely.

Unless the interface only let you do very simple binNMU requests of
single packages, in which case it might not be worth implementing.

--
Sean Whitton

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

gregor herrmann-3
In reply to this post by Holger Levsen-2
On Sun, 07 Jul 2019 02:47:00 +0100, Jonathan Wiltshire wrote:

> There are too many people who should be thanked for their work on getting us to
> this point to list them all individually, and we would be sure to miss some.
> Nevertheless, we would like to particularly thank the installer team, the
> buildd and ftp teams, the CD team, the publicity team, the webmasters, the
> Release Notes editors, porters and all the bug squashers, NMUers, package
> maintainers and translators who have contributed to making buster a great
> release of which we should all be proud.

You indeed missed someone (for obvious reasons): I'd like to thank
the release team for their excellent work!
 
> 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.

That's great news.
 
>   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.

But this part not so much.
 
Forcing hundreds of maintainers to do two uploads for a new package
seems to me like the wrong solution for the conflicting interests of
the ftp team (wants to see binary packages for review in NEW) and the
release team (doesn't want to see binary packages in testing not
built by buildds).

I hope that there will be a better solution for this dilemma in the
not too distant future. If throwing away binaries is too problematic,
as Niels mentioned, maybe SomeThing™ could build a binary package for
the ftp-masters for source-only uploads to NEW. Or people knowing the
whole infrastructure better than me have smarter ideas :)


Cheers,
gregor

--
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Beatles

signature.asc (981 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Adam Borowski-3
On Thu, Jul 11, 2019 at 09:34:07PM +0200, gregor herrmann wrote:
> You indeed missed someone (for obvious reasons): I'd like to thank
> the release team for their excellent work!

+1

> On Sun, 07 Jul 2019 02:47:00 +0100, Jonathan Wiltshire wrote:
> > 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.

> But this part not so much.
>  
> Forcing hundreds of maintainers to do two uploads for a new package
> seems to me like the wrong solution for the conflicting interests of
> the ftp team (wants to see binary packages for review in NEW) and the
> release team (doesn't want to see binary packages in testing not
> built by buildds).

There's also a third concern: we need a way to bootstrap B-Depend cycles.
Such as a self-hosting compiler, cyclical dependencies within an ecosystem,
importing a whole new architecture, etc.

> I hope that there will be a better solution for this dilemma in the
> not too distant future. If throwing away binaries is too problematic,
> as Niels mentioned, maybe SomeThing™ could build a binary package for
> the ftp-masters for source-only uploads to NEW. Or people knowing the
> whole infrastructure better than me have smarter ideas :)

The -ports team has an "unreleased" suite that buildds can use both for
Deps and B-Deps, and people can use before patches are upstreamed.
Something of this kind could be done for binary uploads.

Some dude named Ken Thompson had an insightful comment here, but that's
the easiest solution for now.


Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ According to recent spams, "all my email accounts are owned
⢿⡄⠘⠷⠚⠋  by a hacker".  So what's the problem?
⠈⠳⣄⠀⠀⠀⠀

Reply | Threaded
Open this post in threaded view
|

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

Michael Hudson-Doyle


On Fri, 12 Jul 2019 at 08:17, Adam Borowski <[hidden email]> wrote:
On Thu, Jul 11, 2019 at 09:34:07PM +0200, gregor herrmann wrote:
> You indeed missed someone (for obvious reasons): I'd like to thank
> the release team for their excellent work!

+1

+lots
 
> On Sun, 07 Jul 2019 02:47:00 +0100, Jonathan Wiltshire wrote:
> > 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.

> But this part not so much.

> Forcing hundreds of maintainers to do two uploads for a new package
> seems to me like the wrong solution for the conflicting interests of
> the ftp team (wants to see binary packages for review in NEW) and the
> release team (doesn't want to see binary packages in testing not
> built by buildds).

FWIW in Ubuntu, packages go through NEW as source and then as soon as they build they go back through as binaries. It seems to work OK.
 
There's also a third concern: we need a way to bootstrap B-Depend cycles.
Such as a self-hosting compiler, cyclical dependencies within an ecosystem,
importing a whole new architecture, etc.

But the ban is only on developer-built binaries in testing. So you can upload with binaries to unstable, then once they are published make a source-only upload, the binaries from which will migrate. Sure it's an extra upload or two but it's not that complicated really.

> I hope that there will be a better solution for this dilemma in the
> not too distant future. If throwing away binaries is too problematic,
> as Niels mentioned, maybe SomeThing™ could build a binary package for
> the ftp-masters for source-only uploads to NEW. Or people knowing the
> whole infrastructure better than me have smarter ideas :)

The -ports team has an "unreleased" suite that buildds can use both for
Deps and B-Deps, and people can use before patches are upstreamed.
Something of this kind could be done for binary uploads.

Some dude named Ken Thompson had an insightful comment here, but that's
the easiest solution for now.

Well there's no getting away from that.

Cheers,
mwh
Reply | Threaded
Open this post in threaded view
|

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

Paul Gevers-4
In reply to this post by Lisandro Damián Nicanor Pérez Meyer-2
Hi Lisandro,

On 07-07-2019 16:16, Lisandro Damián Nicanor Pérez Meyer wrote:

>> All autopkgtest failures considered RC for bullseye
>> ===================================================
>>
>> From now on, all autopkgtest failures will be considered release-critical for
>> bullseye. So if your package has failing autopkgtests, now is a good time to
>> start looking for a fix
>
> Now this raises some questions for me. Now I maintain a (huge) library
> (hello Qt!). I do an unstable upload and package A starts failing it's
> autopkgtests. In this case:
>
> - How does this failure affects the uploaded library (imagine we have
> a transition, as it will always be Qt's case due to private headers).
By default, the migration to testing will be blocked, exactly like we
have been doing the last half year.

> - What's expected from the maintainers of the library?

It is expected that you communicate (e.g. via a bug report filed against
both packages like I have been doing for over a year now, see examples
on [1]) with the maintainers of the package to see why the test starts
failing. Together, you should be able to work out which package needs to
adapt. Either the autopkgtest found a real issue in your library which
you need to fix, or the package needs to adapt to the new status of your
library, either by fixing the package itself, or its autopkgtest. The
migration of your library will be stalled to give the package time to be
adapted. Of course that needs to happen within a reasonable amount of
time, so if it takes to long, or you and the maintainers of the package
can't agree on who should adapt what, contact the release team.

Just to be clear, in case you got confused by it, if the package
*already* fails in testing, it isn't a concern for packages that just
trigger that autopkgtest, only for the package with the failing autopkgtest.

I wonder if you were thinking of something else? If so, please elaborate.

Paul

[1]
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-ci@...


signature.asc (499 bytes) Download Attachment
12