I should point out in case it wasn't clear that I'm in favour of this
proposal - I was enumerating all the possible problems I could see from
a devil's-advocate point of view, so that we can make sure there are
solutions to them, rather than trying to make it not happen.
On Mon, 09 Jan 2023 at
> "Andreas" == Andreas Metzler writes:
Andreas> Afaiui Graham's *question* was in response to Bastian's
Andreas> "However, please describe an actionable plan." Obviously it
Andreas> would be a lot easier if we could require to have all NEW
Andreas> uploads go to experimental
On 2023-01-10 Sam Hartman wrote:
> > "Graham" == Graham Inggs writes:
> Graham> Hi All
> Graham> On Fri, 6 Jan 2023 at 00:33, Bastian Blank
> wrote:
> Graham> Would it be a bad thing to require all uploads that need to
> Graham> go through NEW (source and binary) to target
> "Graham" == Graham Inggs writes:
Graham> Hi All
Graham> On Fri, 6 Jan 2023 at 00:33, Bastian Blank 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
Hi All
On Fri, 6 Jan 2023 at 00:33, Bastian Blank wrote:
> 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.
Would it be a bad thing to require
Hello,
On Thu 05 Jan 2023 at 01:13PM GMT, Simon McVittie wrote:
> 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
On Thu, 5 Jan 2023, Simon McVittie wrote:
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?
Yes, you do.
On Thu, Jan 05, 2023 at 02:29:42PM +0100, Sebastian Ramacher wrote:
>
> From recent memory and assuming there are no issues with d/copyright,
> binary-NEW uploads to experimental have been processed swiftly.
This is also my experience that binary-NEW uploads for
library SONAME bumps are handled
On Thu, Jan 05, 2023 at 12:26:09PM +0100, Paul Gevers wrote:
> Once accepted,
> the proposed workflow should also become documented in Debian policy.
As this is no technical policy, this belongs into the developers
reference.
However,
On 1/5/23 12:28, Sebastiaan Couwenberg wrote:
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
+1
On Thu, Jan 05, 2023 at 12:26:09PM +0100, Paul Gevers wrote in a mail with
the subject "SONAME bumps (transitions) always via experimental)":
> Are there objections against this workflow? (Or voices from people who like
> this?)
I like this.
--
cheers
Hi,
On 05-01-2023 14:13, Simon McVittie wrote:
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).
To be fair, normal SONAME bump NEW uploads only need a arch:!all binary
On 1/5/23 14:13, Simon McVittie wrote:
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:
On 2023-01-05 13:13:59 +, Simon McVittie wrote:
> 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
Quoting Paul Gevers (2023-01-05 12:26:09)
> Once accepted, the proposed workflow should also become documented in Debian
> policy.
I think how transitions are done is not even documented in the dev-ref right
now, no?
Last time I was uploading a package for a transition I followed
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
Hi!
Il gio 5 gen 2023, 12:28 Sebastiaan Couwenberg ha
scritto:
> 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.
+1
mfv
On Thu, 5 Jan 2023 at 08:28, Sebastiaan Couwenberg wrote:
>
> 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.
I wholeheartedly agree here,
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
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146
Dear all,
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
20 matches
Mail list logo
