The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 1. RFD: Reorganization of the Debian Project

'Bdale Garbee wrote:'
>
>In article <32A0D333.40B4AEBF@megabaud.fi> you wrote:
>: 
>: Well, even if this can appear foolish, I suggest that Debian should give
>: up releasing distributions.
>
>Fascinating.  I'd like to see this idea get some serious discussion, and not
>just be dismissed out of hand.  We clearly haven't gotten the release thing
>figured out adequately, yet... and it's an angst-generator every time we try
>to do a release.  Maybe we can fix that, maybe we can't.

I agree that some part of "not releasing distributions" is
"fascinating".  When we moved from a.out to ELF, large parts of
"unstable" were /very/ unstable.  Now that dpkg and our policy are more
robust, we don't have big messes in "unstable".  Now, our issues can be
seen as package-by-package improvements.  Of course, some packages
(e.g., the web packages and our web tree standard) are in lock-step
with others.

Perhaps we should change the way packages are placed in the heirarchy.
And we need a way to review packages independent of the bug system to
decide if they are good enough for "stable" or not.  Here's a proposal:

Packages uploaded to Incoming are processed for sanity and installed in
contrib, non-free, or scratch-heap as appropriate by automatic scripts
like we have now.  [Unlike "unstable" "scratch-heap" could contain
multiple versions of packages so it wouldn't be appropriate for dselect
use.  Perhaps each package would have it's own directory?]  Each
package in "scratch-heap" would need votes and/or time before moving to
"stable" as follows:  3 "nay" votes and it's out; 1 "nay" vote from the
maintainer herself and it's out; if three weeks elapse with no "nay"
votes and no newer version from the maintainer, it's in; finally, 3
expedite votes would move a critical package in as soon as the third is
registered and a nightly script is run.

Assumptions of my proposal:
 - every package uploaded to Incoming is thought to be "stable" by its
   maintainer (hey, anyone who I catch intentionally uploading garbage
   for anything except "experimental" will be hearing from me!)
 - except in the case of opposition, packages should be moved to
   "stable" eventually (that's why the maintainer uploaded them
   after all!).
 - we need a mechanism to prevent the natural movement of a package
   into unstable when said package fails to meet requirements (yet
   those requirements should probably never be codified)
 - we need a mechanism to install as "stable" exceptional cases like
   sendmail security bug fixes and etc.
 - these decisions should /not/ depend on whether Ian, Brian, or Bruce had
   time this week to make the best decision for the project.  Instead each
   developer should able to vote on any packages they care about.
 - the voting mechanism would be done by e-mail to a vote@debian.org
   and every vote would be posted to debian-devel for discussion.
   Sorry, anonymous voting isn't allowed ;)
 - we should implement the voting mechanism anyway, we can decide to
   move packages based on votes later

If we had had this voting mechanism, Ian could have sent a
multi-package vote to vote@debian.org.  If two other people saw the
"expedite" vote on debian-devel and agreed with him, they could have
also submitted votes.  If anyone strongly disagreed with them, they
could vote "nay".  Then we need an algorithm that says that 1 "nay" = 3
"expedite" and after everyone who cares voted, we'd know what to do
about X for 1.2 !

I think developer's signing off on packages would be an important
improvement to our release schedule.  I think reorganizing the
"unstable" heirarchy ("scratch-heap") is better in sync with the way
Debian is organized.  However, I suspect we will modify that part of
this proposal before the month ends!

-- 
Christopher J. Fearnley            |    Linux/Internet Consulting
cjf@netaxs.com, cjf@onit.net       |    UNIX SIG Leader at PACS
http://www.netaxs.com/~cjf         |    (Philadelphia Area Computer Society)
ftp://ftp.netaxs.com/people/cjf    |    Design Science Revolutionary
"Dare to be Naive" -- Bucky Fuller |    Explorer in Universe


--
Please respect the confidentiality of material on the debian-private list.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com