Re: Proposal: General Resolution on Init Systems and systemd Facilities

[Scott Kitterman <debian@kitterman.com>]

On November 15, 2019 3:26:31 AM UTC, Russ Allbery <rra@debian.org> wrote:
>Scott Kitterman <debian@kitterman.com> writes:
>
>> This option makes multiple references to RC and non-RC bugs based on
>> actions of the policy editors.
>
>> It's my understanding that determining if a bug is RC or not is a
>> Release Team function, not the policy editors.
>
>> Would it be better to use something like 'severe policy violation'
>(and
>> it's opposite) than Release Critical?
>
>No objections here but I think it's a minor issue.  These are generally
>kept in sync except that the release team is free to declare violations
>of
>a Policy must to not be release-critical in the service of getting a
>release out and scoping the amount of work we're committing to do. 
>(The
>contrary should *not* be true and only is due to lack of resources;
>anything that the release team considers release-critical should be a
>must
>in Policy, and bug reports are welcome in any place this is not in
>sync.)
>
>If a Policy must is declared not release critical for release after
>release, I'd like to synchronize and downgrade it to a should.  The
>goal
>is for both policies to say the same thing except for temporary
>exceptions.

Okay.  My thought is that it's cleaner to state this GR is about the project position on policy and not about the Release Team's execution of its delegated authority if we stay away from the RC terminology.

We may all know what we mean now, but GRs seem to get referenced for a very long time.  I think it's worth it for 15 years from now Debian to be as clean and clear as we can now.

Scott K