On 25/04/08 at 18:32 +0200, Nico Golde wrote: > What about introducing a special case regarding the waiting > period before uploading an NMU for security bugs? There are > often cases in which we already have a patch handy to fix a > security issue but still wait a few days on the maintainers > reaction. On 26/04/08 at 20:22 +0200, Thijs Kinkhorst wrote: > On Saturday 26 April 2008 02:07, Don Armstrong wrote: > > On Sat, 26 Apr 2008, Paul Wise wrote: > > > I'd prefer the security team did not delay fixes at all by default. > > > Exceptions for specific maintainers, transitions or other reasons > > > are fine too of course. > > > > For stable and testing, I agree. However, for unstable and > > experimental the maintainer should be at least given a chance to > > resolve the issue. [That is to say, I object to filing a bug and > > immediately NMUing for unstable; in almost all cases the bug should be > > a few days old before that happens.] > > I agree with that. The cases where the available "patch" for a security issue > was insufficient or broke other things are not quite rare. The maintainer of > a package is the first one responsible for it and should be given the > opportunity to comment on the patch and/or apply it himself. At least a few > days, and of course depending on the impact of the bug: no need to rush in > patches for low impact bugs. I don't think that developers-reference is the good place to list all the special cases. In the DEP, we include some example delays: | While there are no general rules, it's recommended to upload to the | DELAYED queue with a delay of at least a few days. Here are some | examples that you could use as default values: | # Upload fixing only release-critical bugs older than 7 days: 2 days | # Upload fixing only release-critical and important bugs: 5 days | # Other NMUs: 10 days Those are example delays, not mandatory ones. If the uploader thinks that he has a good reason to wait less time, he can still wait less time. I've added this sentence after the above examples to clarify this: | Those delays are only examples. In some cases (uploads fixing security | issues, trivial bugfixes blocking a transition, ...), it is desirable | that the fixed package reaches unstable sooner. -- | Lucas Nussbaum | lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
Attachment:
signature.asc
Description: Digital signature