On Sun, Jul 04, 1999 at 01:57:45PM +0200, Richard Braakman wrote: > > I would suggest refrigeration for the moment. Traditionally when we > > freeze we tell people not to upload new versions of software---not even > > new versions of stable software---unless important bugs are fixed by > > doing so. What I'd like to see is NEW software not being automatically > > accepted for potato. This to keep new packages from making it harder to > > get the bug count down. > > Hmm, I am not happy with such an approach, because it leaves no place > for new packages to go. During a freeze, we can be selective about > what goes into frozen, because everything else can go to unstable. I think we would link potato to frozen, we'd just make sure it's generally known that we're not dealing with a hard or deep freeze. > Also, when I look at the release-critical bugs list, I do not > see many new packages. Or did you mean the total bug count? > Indeed, [archive maintainer hat] most new packages have a number > of bugs when they are first uploaded, and I've wondered if I should > be more eager to reject them. I'd suggest just putting them in a new unstable. But all major changes should happen simultaneously with frozen and potato, the object being to not count every new package that comes along for release at the moment, but making sure that unstable isn't a different version yet. > > Hopefully this will help people concentrate on fixing bugs. > > Will it? I think the ensuing flame war would be distracting :-) > (We've had this discussion before on this list, and I saw a lot > of disagreement.) > > I may have misunderstood you. Did you mean actually freezing, > with a new unstable and all, and accepting updates to existing > packages in frozen automatically? That might work, if dinstall > ignores the "Distribution" header in the .changes file. Otherwise, > updates will effectively only go to the new unstable because they > are usually uploaded to "unstable". A soft freeze, yes. And while you're mucking around with dinstall, should I send you a requested feature list? =D > > For an example of the problem, look at afterstep. [...] > > > > In such cases developers should be able to NMU these packages without > > worrying about complaints of package hijacking. Although in the case of > > afterstep, hijacking it doesn't seem like such a bad idea... > > Maybe I should explain the Secret Master Plan inherent in my first plan :-) > The mails sent to each maintainer will specifically ask them if they > would mind an NMU to fix the release-critical bugs. Josip will keep > track of when each bug was asked about, and what the replies were. > > Maintainers that have gone missing will not reply, and this information > will go appear in the release-critical bugs summary, thus making it a > handy database for the QA folks. <AOL>Good plan.</AOL> > As for afterstep... maybe we should write out a policy for taking over > a package. It seems to me that if you have queried the maintainer a > number of times, and have allowed sufficient time for responses, and > have asked about him and the package on debian-devel, then it is > reasonable to take over the package. (I also think it is reasonable > in a lot of other cases, but this should be a minimum we can all > agree on :-) I'll have to look to see if the constitution covers this, I don't recall offhand. If it does not, we HAVE such a policy, though informal. It was explained to me that if a maintainer appears to have gone MIA and isn't taking care of the package you post an intent to adopt to -devel and Cc the maintainer. If after a reasonable amount of time they have not answered, you adopt the package. This is part of why the announcement of vacations, as I understand it. If someone will be away, their packages may need maintenance and they don't want us to think them MIA... I'm pretty sure this came up with the constitution, I just forget if it changed as a result. => If not, it's a sane policy given sane people. Of course we're not sane people, we're developers. -- Joseph Carter <knghtbrd@debian.org> Debian GNU/Linux developer PGP: E8D68481E3A8BB77 8EE22996C9445FBE The Source Comes First! ------------------------------------------------------------------------- <woot> Put *that* in you .sig and smoke it, Knghtbrd. <Culus> You know he will read this :> <woot> heheheheh.
Attachment:
pgpGeMtceoMo2.pgp
Description: PGP signature