Bug#1077764: Ruling request on os-release specification implementation

On Mon, 5 Aug 2024 at 12:21, Luca Boccassi <[email protected]> wrote:
>
> On Mon, 5 Aug 2024 at 03:15, Sean Whitton <[email protected]> wrote:
> >
> > Hello,
> >
> > So far, although many people are sympathetic to the frustration at
> > distinguishing testing from unstable in practice, I don't believe anyone
> > has spoken in favour of overriding Santiago, besides Luca.
>
> To clarify, do you mean "TC members" here instead of the more generic
> "people"? Because there have been a few people speaking in favour,
> with varying degrees of enthusiasm. But please note that I have not
> publicized this anywhere, so only somebody who follows CTTE's bugs
> would have noticed. If you are looking for more people (outside of TC
> members) to chime in, I can try and make that happen, but I wasn't
> aware this was a requirement.
>
> > Also, the Release Team aren't happy with Luca's plan, so even if the TC
> > were to override Santiago, it might be moot, because the TC can't
> > override delegate decisions.
>
> That is not how I read those messages though? I do not see vetoes.
> There were legitimate concerns raised about QA efforts, and manual
> efforts, which I think I have answered - at least there hasn't been
> any comeback on those answers.
>
> As far as I can tell, testing-proposed-updates is a fully supported
> mechanism, our dev ref even mentions it:
>
> https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#t-p-u
>
> I believe the change being talked about respects all the points and
> requirements listed on that page. If there are more that are not
> present there, I would ask that they be documented in the same place -
> this would generally be useful, not just for this instance.

Also, using t-p-u is only one mechanism, there are more mentioned in
another mail. I'd rather not do extra work if a better mechanism is
there, but if that cannot be used for any reason, then I would do such
extra work and avoid t-p-u.

As mentioned before, I am not asking to modify testing/trixie in any
way. I am asking to modify sid. If what I propose was implemented
right now, trixie would be exactly as it is now. It's sid that would
change from VERSION_CODENAME=trixie to VERSION_CODENAME=sid.