>>>>> "Ben" == Ben Hutchings <b...@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
