Are there objections against this workflow? (Or voices from people who
On 1/5/23 12:26, Paul Gevers wrote:
Are there objections against this workflow? (Or voices from people who
This has been a best practice for quite a while, high time to make it
hard requirement.
On 1/5/23 12:26, Paul Gevers wrote:
Are there objections against this workflow? (Or voices from people who
This has been a best practice for quite a while, high time to make it
hard requirement.
The Release Team just asked ftp-master to hold of accepting SONAME bumps targeting unstable to ease the last days before the Transition and Toolchain Freeze. The Release Team would like to ask the ftp-masters to also by
default reject SONAME bump NEW uploads to unstable during the whole release cycle and instead mandate they need to go through experimental.
Once accepted, the proposed workflow should also become documented in Debian policy.
The benefits of all SONAME bump NEW uploads going through experimental
are at least:
* disentangle the start of transitions from NEW acceptance by ftp-master
* auto transition trackers [1] are setup before the start of transitions
* reduce the chance of uploads accidentally interfering with ongoing
transitions (by more awareness and exposure via tracker.d.o).
Are there objections against this workflow? (Or voices from people who
like this?)
On Thu, 05 Jan 2023 at 12:26:09 +0100, Paul Gevers wrote:
The Release Team just asked ftp-master to hold of accepting SONAME bumps targeting unstable to ease the last days before the Transition and Toolchain
Freeze. The Release Team would like to ask the ftp-masters to also by default reject SONAME bump NEW uploads to unstable during the whole release cycle and instead mandate they need to go through experimental.
That seems like a good policy, and many maintainers already do that,
either because the new SONAME needs more testing before its transition
or to make sure they can upload bug fixes to testing/unstable while
waiting for NEW acceptance of the newer version (without risking those
bug fixes being superseded by the new version at the unpredictable time
that it gets accepted from NEW).
The only potential problems I can see are:
1. It results in more uploads (to experimental and then again to unstable),
which maintainers might consider to be a high cost for packages that
only have a few tightly-coupled rdeps. I don't think this is really
a big problem, particularly since passing NEW currently requires a
source+binary upload but migrating to testing requires a follow-up
source-only upload (same total number of uploads).
2. If there is already a version in experimental that is unsuitable for
the next stable release, because there's only one experimental, in the
rare case that upstream bumps the SONAME of the "old" branch, we can't
do as asked. For example:
- libfoo_1.0-1 (libfoo-1.so.0) is in testing/unstable
- libfoo_2.0-1 (libfoo-2.so.0) is in experimental but not yet ready
- maintainer wants to get libfoo 1.5 (libfoo-1.so.1) into testing/unstable
This seems unlikely to happen often, because upstreams usually focus
development of intrusive changes that can break ABI onto one branch at
a time. Presumably if a maintainer finds that they need this, the ftp
team would read a justification in debian/changelog and relax this rule?
If bikesheds ever become available, then they would solve all instances
of the "only one experimental" problem, including this one.
3. If the ftp team prioritize NEW review of unstable packages higher than
experimental packages (do they?) then that would be
counter-productive under the proposed policy, and they'd have to
stop doing that (and perhaps prioritize binary-NEW higher than
source-NEW, instead). experimental packages appear in red on
https://ftp-master.debian.org/new.html, which makes me wonder whether
that reflects those packages being de-prioritized, but perhaps I'm
reading too much into that?
From recent memory and assuming there are no issues with d/copyright, binary-NEW uploads to experimental have been processed swiftly.
2. If there is already a version in experimental that is unsuitable for
the next stable release, because there's only one experimental, in the
rare case that upstream bumps the SONAME of the "old" branch, we can't
do as asked. For example:
- libfoo_1.0-1 (libfoo-1.so.0) is in testing/unstable
- libfoo_2.0-1 (libfoo-2.so.0) is in experimental but not yet ready
- maintainer wants to get libfoo 1.5 (libfoo-1.so.1) into testing/unstable
This seems unlikely to happen often, because upstreams usually focus
development of intrusive changes that can break ABI onto one branch at
a time. Presumably if a maintainer finds that they need this, the ftp
team would read a justification in debian/changelog and relax this rule?
If bikesheds ever become available, then they would solve all instances
of the "only one experimental" problem, including this one.
On 1/5/23 12:26, Paul Gevers wrote:
Are there objections against this workflow? (Or voices from people who
This has been a best practice for quite a while, high time to make it
hard requirement.
Kind Regards,
Bas
Once accepted, the proposed workflow should also become documented in Debian policy.
From recent memory and assuming there are no issues with d/copyright, binary-NEW uploads to experimental have been processed swiftly.
3.
experimental packages appear in red on
https://ftp-master.debian.org/new.html, which makes me wonder whether
that reflects those packages being de-prioritized, but perhaps I'm
reading too much into that?
3. If the ftp team prioritize NEW review of unstable packages higher than
experimental packages (do they?) then that would be
counter-productive under the proposed policy, and they'd have to
stop doing that (and perhaps prioritize binary-NEW higher than
source-NEW, instead). experimental packages appear in red on
https://ftp-master.debian.org/new.html, which makes me wonder whether
that reflects those packages being de-prioritized, but perhaps I'm
reading too much into that?
However, please describe an actionable plan. What do you want to be rejected, in a codified form.
It would be nice if you could provide a patch for process-new that
displays this information.
"Graham" == Graham Inggs <ginggs@debian.org> writes:
Graham> Hi All"Graham" == Graham Inggs <ginggs@debian.org> writes:
Graham> On Fri, 6 Jan 2023 at 00:33, Bastian Blank <waldi@debian.org> wrote:
Graham> Would it be a bad thing to require all uploads that need to
Graham> go through NEW (source and binary) to target experimental?
Graham> I have been doing this for my own, and sponsored, uploads
Graham> for some years already.
Also, I'm less convinced there's a good reason for source new uploads to target experimental.[...]
If it's a new package with entirely new binary packages, it shouldn't be involved in any transitions.
Andreas> Afaiui Graham's *question* was in response to Bastian's"Andreas" == Andreas Metzler <ametzler@bebt.de> writes:
I think what Paul, Simon and apparently I are asking for is that
maintainers be able to explain why they are sending an upload that needs
to go through new to unstable in the changelog and have ftpmaster
consider whether their reason is good.
Also, I'm less convinced there's a good reason for source new uploads to target experimental.
If it's a new package with entirely new binary packages, it shouldn't be involved in any transitions.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (1 / 15) |
| Uptime: | 159:49:56 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,056 |
| Messages: | 6,416,491 |