NEW queue and src-only uploads [Re: Bits from the Release Team: ride like the wind, Bullseye!]

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

NEW queue and src-only uploads [Re: Bits from the Release Team: ride like the wind, Bullseye!]

Michael Biebl-3
Am 07.07.19 um 15:43 schrieb Ben Hutchings:

> On Sun, 2019-07-07 at 02:47 +0100, Jonathan Wiltshire wrote:
> [...]
>> 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.
>
> I support this move in principle, but:
>
>>   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.
> [...]
>
> This is not going to fly for src:linux.  We can't stage ABI bumps in
> experimental as we typically have a different upstream versions in
> unstable and experimental.  We even need to do ABI bumps in stable from
> time to time.
>
> I think that the requirement to upload binary packages for binary-NEW
> (but not source-NEW) needs to go.
I would go even further and drop the (manual) NEW queue for  binary-NEW
packages.
Is there a good reason why new binary packages need manual processing by
the FTP team? Couldn't this be fully automated?

Michael

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?


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

Re: NEW queue and src-only uploads [Re: Bits from the Release Team: ride like the wind, Bullseye!]

Sean Whitton
Hello,

On Mon 08 Jul 2019 at 02:02PM +02, Michael Biebl wrote:

> I would go even further and drop the (manual) NEW queue for  binary-NEW
> packages.
> Is there a good reason why new binary packages need manual processing by
> the FTP team? Couldn't this be fully automated?

The three things the FTP team check[1] are worth doing again for
binary-NEW packages.  In order: there are often lots of new files in an
upload that ends up in binary-NEW so there might be licensing issues; a
new binary package means a new member of the binary package namespace;
it's good to have a second pair of eyes look at your SONAME bump etc.

[1]  https://ftp-master.debian.org/REJECT-FAQ.html right at the top

--
Sean Whitton

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

Re: NEW queue and src-only uploads [Re: Bits from the Release Team: ride like the wind, Bullseye!]

Roberto C. Sánchez-2
On Tue, Jul 09, 2019 at 01:33:49PM +0100, Sean Whitton wrote:

> Hello,
>
> On Mon 08 Jul 2019 at 02:02PM +02, Michael Biebl wrote:
>
> > I would go even further and drop the (manual) NEW queue for  binary-NEW
> > packages.
> > Is there a good reason why new binary packages need manual processing by
> > the FTP team? Couldn't this be fully automated?
>
> The three things the FTP team check[1] are worth doing again for
> binary-NEW packages.  In order: there are often lots of new files in an
> upload that ends up in binary-NEW so there might be licensing issues; a
> new binary package means a new member of the binary package namespace;
> it's good to have a second pair of eyes look at your SONAME bump etc.
>
> [1]  https://ftp-master.debian.org/REJECT-FAQ.html right at the top
>
I've always wondered about this.

Why is it, then, that binary-NEW still applies if there have been no
source files added/removed?  (A SONAME bump possibly being necessitated
by some change that does not involve adding/removing/renaming source
files.)

Following on that, what about a package that does add/remove source
files (perhaps many) without a SONAME bump or other change that results
in a new binary package?

It seems like reviewing the package name space on introduction of a new
binary package and an additional review of a SONAME bump are good things
and the binary-NEW criteria seem to fit.  However, the "there might be
new source files with licensing issues" does not seem to be a good fit
for binary-NEW criteria.  Not to say that it matters much in the context
of binary-NEW.  But if catching potential licensing issues associated
with large source changes is in fact something which the FTP team wishes
to be able to do, it probably warrants a different filter than "adds a
new binary package to the archive" in order to be effective.

Regards,

-Roberto

--
Roberto C. Sánchez

Reply | Threaded
Open this post in threaded view
|

Re: NEW queue and src-only uploads [Re: Bits from the Release Team: ride like the wind, Bullseye!]

Sean Whitton
Hello,

On Tue 09 Jul 2019 at 08:45AM -04, Roberto C. Sánchez wrote:

> Why is it, then, that binary-NEW still applies if there have been no
> source files added/removed?  (A SONAME bump possibly being necessitated
> by some change that does not involve adding/removing/renaming source
> files.)

For the addition to the binary package namespace to be reviewed.

> Following on that, what about a package that does add/remove source
> files (perhaps many) without a SONAME bump or other change that results
> in a new binary package?

Same again.

> It seems like reviewing the package name space on introduction of a new
> binary package and an additional review of a SONAME bump are good things
> and the binary-NEW criteria seem to fit.  However, the "there might be
> new source files with licensing issues" does not seem to be a good fit
> for binary-NEW criteria.  Not to say that it matters much in the context
> of binary-NEW.  But if catching potential licensing issues associated
> with large source changes is in fact something which the FTP team wishes
> to be able to do, it probably warrants a different filter than "adds a
> new binary package to the archive" in order to be effective.

The FTP team can't check every single upload, so I guess that at some
point someone decided that checking every binary-NEW upload was a
sensible compromise.

More sophisticated filtering on what gets checked would probably be a
good idea, but that would need someone to implement it.

--
Sean Whitton

signature.asc (847 bytes) Download Attachment