[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: so what? Re: Debian development modem

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

> 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

Reply to: