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

Re: splitting experimental by arch?



ydirson@a2points.com (Yann Dirson)  wrote on 03.02.98 in <[🔎] 199802032217.XAA06895@ppp37.a2points.com>:

> * ongoing-work: things that may be one day promoted to unstable, but
> cannot in their present state because the upstream is not ready for
> this.

> * experimental: things that may break something (ie. alpha)

I think that's an unnecessary distinction.

IMHO, a useable definition for experimental would be:

- Packages that are known (or suspected) to be broken in a fundamental way
  (this may make them dangerous or only useless)
- Packages that are not complete in a fundamental point (but are there so
  people can look at them and comment)

That is, Packages that have some really fundamental problem. And  
"experimental" seems an ideal name for this condition.

Besides some more directory structure, one thing I'd like to see is, for  
each package in experimental, a simple README that explains just why that  
package is in experimental, and how the maintainer expects users to handle  
the package.

"Deity is in experimental because it doesn't really work yet. We'd like  
comments on the user interface sent to some@where."

"Xemacs 42.0 is in experimental because right now, editing text files is  
completely broken. However, M-x convert-win32-binary-package-to-debian- 
source-package seems to work perfectly. No guarantees, though."

MfG Kai


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .


Reply to: