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; """
signature.asc
Description: OpenPGP digital signature
