Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #64386 > unrolled thread

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

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Bits from the Release Team: ride like the wind, Bullseye! Ben Hutchings <ben@decadent.org.uk> - 2019-07-07 15:50 +0200
    Re: Bits from the Release Team: ride like the wind, Bullseye! Sam Hartman <hartmans@debian.org> - 2019-07-07 16:20 +0200
    Re: Bits from the Release Team: ride like the wind, Bullseye! Ivo De Decker <ivodd@debian.org> - 2019-07-21 16:20 +0200
      Re: Bits from the Release Team: ride like the wind, Bullseye! Ben Hutchings <ben@decadent.org.uk> - 2019-08-05 18:50 +0200
        process-upload issue (was: Re: Bits from the Release Team: ride  like the wind, Bullseye!) "Adam D. Barratt" <adam@adam-barratt.org.uk> - 2019-08-05 20:30 +0200
          Re: process-upload issue (was: Re: Bits from the Release Team: ride  like the wind, Bullseye!) Ben Hutchings <ben@decadent.org.uk> - 2019-08-12 02:40 +0200
      Re: Bits from the Release Team: ride like the wind, Bullseye! Ben Hutchings <ben@decadent.org.uk> - 2019-10-03 21:40 +0200

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

[Multipart message — attachments visible in raw view] — view raw

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.

Ben.

-- 
Ben Hutchings
Time is nature's way of making sure that
everything doesn't happen at once.

[toc] | [next] | [standalone]

#64388

>>>>> "Ben" == Ben Hutchings <ben@decadent.org.uk> writes:

    Ben> On Sun, 2019-07-07 at 02:47 +0100, Jonathan Wiltshire wrote:
    Ben> [...]
    >> 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.

    Ben> I support this move in principle, but:


    Ben> This is not going to fly for src:linux.  We can't stage ABI
    Ben> bumps in experimental as we typically have a different upstream
    Ben> versions in unstable and experimental.  We even need to do ABI
    Ben> bumps in stable from time to time.

    Ben> I think that the requirement to upload binary packages for
    Ben> binary-NEW (but not source-NEW) needs to go.

I agree with Ben.  There are a lot of good reasons to stage (possibly
even most) binary new packages through experimental.
Ben has talked about cases where experimental can't work.
I'd like to talk about cases where it is the wrong answer.

However, we've gotten a lot of feedback from our maintainers over the
years that anything that adds an extra round trip to their workflow is
significantly demotivating.
If I need to wait for something to go through new, and then after it
goes through new do an extra thing to accomplish my goal, that increases
the cost of what I'm doing significantly.

If it's a simple soname bump because of a new symbol, that doesn't
always require experimental.  Thinking back to my own experience with
krb5, I have a good handle on when ABI bumps need to go through
experimental and when things are going to be fine through unstable.  I
haven't made a lot of mistakes in that front--uploading things to
unstable that ended up being broken enough we wished they had gone
through experimental.

I know I'm not alone.

I think that for this to fly, binaries for binary new need to go.

I understand that balancing the trade offs here requires a bit of a mind
meld between the ftp team and the release team, and I understand that
cross team decision making is more complex here.
I'd be happy to facilitate any discussion around the trade offs if that
would be useful.

--Sam

[toc] | [prev] | [next] | [standalone]

#64508

Hi Ben,

Sorry for not getting back to you about this earlier.

On 7/7/19 3:43 PM, Ben Hutchings wrote:
> 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.

We are aware that src:linux is a special case here. I added an exception 
for the arch:all binaries from src:linux. When the next ABI bump in 
unstable happens, feel free to let me know, so that I can check if it 
works as expected.

Thanks,

Ivo

[toc] | [prev] | [next] | [standalone]

#64643

[Multipart message — attachments visible in raw view] — view raw

On Sun, 2019-07-21 at 10:55 -0300, Ivo De Decker wrote:
[...]
> We are aware that src:linux is a special case here. I added an exception 
> for the arch:all binaries from src:linux. When the next ABI bump in 
> unstable happens, feel free to let me know, so that I can check if it 
> works as expected.

I uploaded a new version (5.2.6-1) to unstable today (11:35 UTC), and
the upload was acknowledged (11:40 UTC) but it hasn't yet showed up in
the NEW queue.

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein

[toc] | [prev] | [next] | [standalone]

#64644 — process-upload issue (was: Re: Bits from the Release Team: ride like the wind, Bullseye!)

[CC += ftpmaster]

On Mon, 2019-08-05 at 17:49 +0100, Ben Hutchings wrote:
> On Sun, 2019-07-21 at 10:55 -0300, Ivo De Decker wrote:
> [...]
> > We are aware that src:linux is a special case here. I added an
> > exception for the arch:all binaries from src:linux. When the next
> > ABI bump in unstable happens, feel free to let me know, so that I
> > can check if it works as expected.
> 
> I uploaded a new version (5.2.6-1) to unstable today (11:35 UTC), and
> the upload was acknowledged (11:40 UTC) but it hasn't yet showed up
> in the NEW queue.

That looks like a problem on the archive side. The dak log suggests an
issue logging an issue with a .changes file:

20190805181929|process-upload|dak|exception|Traceback (most recent call last):
20190805181929|process-upload|dak|exception|  File "/usr/local/bin/dak", line 228, in main
20190805181929|process-upload|dak|exception|    module.main()
20190805181929|process-upload|dak|exception|  File "/srv/ftp-master.debian.org/dak/dak/process_upload.py", line 591, in main
20190805181929|process-upload|dak|exception|    process_changes(changes_files)
20190805181929|process-upload|dak|exception|  File "/srv/ftp-master.debian.org/dak/dak/process_upload.py", line 502, in process_changes
20190805181929|process-upload|dak|exception|    Logger.log([filename, "Error while loading changes: {0}".format(e)])
20190805181929|process-upload|dak|exception|UnicodeEncodeError: 'ascii' codec can't encode character u'\ufffd' in position 223: ordinal not in range(128)

Regards,

Adam

[toc] | [prev] | [next] | [standalone]

#64746 — Re: process-upload issue (was: Re: Bits from the Release Team: ride like the wind, Bullseye!)

[Multipart message — attachments visible in raw view] — view raw

On Mon, 2019-08-05 at 19:25 +0100, Adam D. Barratt wrote:
> [CC += ftpmaster]
> 
> On Mon, 2019-08-05 at 17:49 +0100, Ben Hutchings wrote:
> > On Sun, 2019-07-21 at 10:55 -0300, Ivo De Decker wrote:
> > [...]
> > > We are aware that src:linux is a special case here. I added an
> > > exception for the arch:all binaries from src:linux. When the next
> > > ABI bump in unstable happens, feel free to let me know, so that I
> > > can check if it works as expected.
> > 
> > I uploaded a new version (5.2.6-1) to unstable today (11:35 UTC), and
> > the upload was acknowledged (11:40 UTC) but it hasn't yet showed up
> > in the NEW queue.
> 
> That looks like a problem on the archive side. The dak log suggests an
> issue logging an issue with a .changes file:
> 
> 20190805181929|process-upload|dak|exception|Traceback (most recent call last):
> 20190805181929|process-upload|dak|exception|  File "/usr/local/bin/dak", line 228, in main
> 20190805181929|process-upload|dak|exception|    module.main()
> 20190805181929|process-upload|dak|exception|  File "/srv/ftp-master.debian.org/dak/dak/process_upload.py", line 591, in main
> 20190805181929|process-upload|dak|exception|    process_changes(changes_files)
> 20190805181929|process-upload|dak|exception|  File "/srv/ftp-master.debian.org/dak/dak/process_upload.py", line 502, in process_changes
> 20190805181929|process-upload|dak|exception|    Logger.log([filename, "Error while loading changes: {0}".format(e)])
> 20190805181929|process-upload|dak|exception|UnicodeEncodeError: 'ascii' codec can't encode character u'\ufffd' in position 223: ordinal not in range(128)

Thanks for that.  Both my uploads last week seem to have been processed
successfully, but neither of them built on all release architectures so
we haven't yet been able to see whether the special case works.

Ben.

-- 
Ben Hutchings
Humour is the best antidote to reality.

[toc] | [prev] | [next] | [standalone]

#65312

[Multipart message — attachments visible in raw view] — view raw

On Sun, 2019-07-21 at 10:55 -0300, Ivo De Decker wrote:
> Hi Ben,
> 
> Sorry for not getting back to you about this earlier.
> 
> On 7/7/19 3:43 PM, Ben Hutchings wrote:
> > 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.
> 
> We are aware that src:linux is a special case here. I added an exception 
> for the arch:all binaries from src:linux. When the next ABI bump in 
> unstable happens, feel free to let me know, so that I can check if it 
> works as expected.

linux version 5.2.17-1 was the first version that included an ABI bump
and did not have any regressions that blocked it from testing.  It has
transitioned to testing including the developer-built arch:all
packages, so I believe that this exception works.  Thank you!

Ben.

-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web