On Mon, 5 Aug 2024 at 13:04, Luca Boccassi <bl...@debian.org> wrote: > > On Mon, 5 Aug 2024 at 08:42, Helmut Grohne <hel...@subdivi.de> wrote: > > > > Hi Gioele, > > > > On Mon, Aug 05, 2024 at 08:34:41AM +0200, Gioele Barabucci wrote: > > > as the maintainer (and upstream author) of the current lsb_release > > > implementation used in Debian and derivatives (src:lsb-release-minimal), > > > I'd > > > like to voice my support in favor of having enough information in > > > /usr/lib/os-release to be able to tell "testing" and "unstable" apart. > > > > thanks for speaking up. > > > > > Couldn't the CTTE just rule on the question: > > > > > > * should Debian provide a way to distinguish between the two > > > similar-but-not-identical, rolling, ephemeral releases called "testing" > > > and "staging" via /etc/os-release? > > > > > > and leave the details of how to implement that decision (dependencies, > > > Essential:ye, uploads, releases, etc...) to the involved parties? > > > > My understanding of the constitution is that this is not something we > > can rule. Consider 6.3.5: > > > > | The Technical Committee restricts itself to choosing from or adopting > > compromises between solutions and decisions which have been proposed and > > reasonably thoroughly discussed elsewhere. > > > > Leaving these details out of scope of the decision would further > > entrench the conflict as it would be unclear how the responsibility of > > the os-release metadata would be transitioned and I would expect further > > disagreement on that aspect. > > > > The primary method proposed by Luca intends to leverage t-p-u, which has > > been nacked by two release team members. As such selecting that option > > would imply overruling DPL delegates, which also is not a power of the > > CTTE. > > Maybe I'm too optimistic, but again in my reading I do not see vetoes, > I see valid concerns that I believe I responded to. I believe Gioele's > proposal that I adopted meets these criterias: > > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#t-p-u > > Again, if those criterias are incomplete, then I'd ask that > documentation be brought up to date, as this is a generic mechanism, > and having everything needed to use it documented is beneficial for > the project at large, outside of this one instance.
And to be clear, of course if RT now replies with something along the lines of "this is an official veto to the use of t-p-u from RT", then I'll pick one of the alternatives that do not involve t-p-u
