On 2015-08-24 21:24, Santiago Vila wrote:
> [...]
>
Hi Santiago,
> Making a great percentage of packages in the archive to be "suddenly"
> buggy is unacceptable.
>
I can see where you are coming from. I have to admit that I am
personally not too concerned with the severity change. Given it is not
release critical, it is not going to throw packages out of testing or
anything like that. But as Enrico taught us: YKINMKBYKIOK :)
> We all want Debian to build reproducibly, but goals are achieved by
> submitting bugs, changing packages and making uploads, not by rising
> severities.
>
I agree in general that people should make an effort to improve the
situation before trying to solve this by simply "inflating" the
severity. However, in this case, I feel that the reproducibility team
has done quite an effort to reach this point already.
In your opinion, how much of the archive should be fixed before one can
start bumping the severity?
* Personally, I considered the >80% fixed is quite convincing, but I
would like to hear you take on this.
> It is really so much difficult to make this in stages?
> For example:
>
> Stage 1. Make it a policy *recommendation*, with normal severity.
> Stage 2. Make it a policy "should", with important severity.
> Stage 3. Make it a release goal, policy "must", with serious severity.
>
It would be great if Policy was updated so frequently that was up to
speed with current initiatives in Debian. However, historically, it
often lacks behind on many key parts. Including but not limited to
Multi-Arch (released with Wheezy), which is currently still not
documented in policy (nor in git for the next upload).
Thanks,
~Niels
--
Also, contrary to popular belief:
Policy does *not* decide if something is an RC bug or not.
That is currently delegated to the Release Team[1], which means that
https://release.debian.org/stretch/rc_policy.txt
is the canonical policy for what is release critical and what is not.
[1] https://lists.debian.org/debian-devel-announce/2013/12/msg00007.html
"""
* Release Team members define the content of the suites listed above,
that is:
+ They define the packages that are part of those suites. Generally,
that is achieved:
- by deciding which issues are release-critical (RC) -- making the
affected packages not suitable for stable releases -- usually by
setting the corresponding bug's severity to serious, grave or
critical;
"""
Attachment:
signature.asc
Description: OpenPGP digital signature