On Thu, May 28, 1998 at 02:23:57AM -0400, James A. Treacy wrote: > There are a lot of people using packages every day that aren't formally > contributing to the testing project. Yes, but many of these users DO contribute bug reports. I think the biggest hurdle to the system I've suggested is that bug.debian.org has several long outstanding bugs on it. > I have thought a (little) bit about a system along the lines you mention. > We could create a web page for every package in unstable that hasn't gone > into stable yet. When someone has installed a package, they could go to > the page for that package and fill out a form. The package can get into > stable only when certain criteria have been met. The criteria could depend > on the package. For a simple library, having 5 people install and use it > (and fill out the form) might be sufficient. A package with a lot more > users might require more responses, e.g. TeX needs 20 people to fill out > the form. A package which requires configuration (like smail) may not only > need a larger number of people to fill out the form, but a sufficient > number of people with each type of configuration (the form provides a > list). This is an interesting way to do it. I have a better idea though. => Urgency in the control file. Urgency of most packages is low. These packages can be considered unstable perhaps a month. If no "release critical" bugs are outstanding on this version of the package (not subversion) it can be moved to stable. So my_package 1.4.2-1 has a grave or critical bug in it. Two weeks later, 1.4.2-2 fixes it. In another 2 weeks, it could go stable.. There might need to be some exceptions, but usually the places exceptions are needed shouldn't be low urgency, hm? Medium and high urgency would of course be shorter times since they are higher urgency for reasons. I might suggest adding an urgency critical or very_high or whatever you wanna call it then for things like patches to IP exploits in a stable kernel. => These things CANNOT wait. > There are two problems with this. First is security. We want all users to > be able to fill out the forms, but how do we keep evil minded people from > ruining the results. Second, is designing a framework that is simple, but > accomplishes the required goals. > > If simple is the right way to go, there could simply be a line in the > control file specifying the number of people that need to fill out the > form (with a positive response) before the package is allowed into stable. mmm I can see one more problem with this: I for one sure won't take the time to do this by hand and there's no way in hell I'm gonna let the system automagically report what software I'm using. I think instead fixing the bug system would be better. It's been mentioned that Debian developers are kinda skitzophrenic.. Some want a community development where everyone's contributions matter and anyone can contribute and any release we make is solid. Others want consistant releases with the latest stuff so they don't have to be part of the development community and able to fix any problems that crop up to get newer software with recent features. This would IMO be a MORE community based organization and would get software that is ready for release out a lot sooner, hopefully satisfying more people, INCLUDING the CD-ROM vendors who kinda like having new product to sell every few months.. Some of their customers (me) will probably quite frequently buy the newest CD-ROMs just so I have installation media of fairly recent (even if out of date by a month or two) software. I run slink packages now, but still plan to buy a hamm CD set when it ships for that reason. > There are a number of issues that I have intentionally ignored in this. I > am just throwing this out to see what people think. Like the privacy issue? => The BIGGEST issue about any idea of the sort starting with mine, including yours, and several others like it is this: Can stable actually be kept stable in a system like this or would compromises cause stability to go down? I think probably we could do it since hopefully the above suggestions I made as for what it would take to get a package in to stable faster would be policy. Thoughts anyone?
Attachment:
pgp5ZN6k4zLc0.pgp
Description: PGP signature