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

'Vociferous Mole wrote:'
>
>[This started as a short reply to Chris, and developed into
>a long boring ramble. You have been warned.]

Do you mean a reply to my idea of developers having veto power over
packages and using 3 weeks or some similar time frame for moving a
package if it wasn't vetoed?

A pretty good ramble though :)

>I've been reading these threads, and my first thought was "Yeah,
>why are we so hung up on releases: we've got incremental upgrades",
>but I wasn't really comfortable with it, and Lars clarified (for
>me, at least) why releases *are* important.

I agree that releases are important.  In my veto scheme, the releases
could come every 3 or 4 months as now.

>I think most of our agony over releases has been because we are
>still changing the target right up to the last bitter moment. We
>need to layout the goals for 1.3 *now*, set the date (april 1?),

The "goals" for new releases have been vague (in the sense that they
had not been stamped on Brian's list) and unenforceable (which is good
-- it's the way I like it)  The problem as I see it is how to agree
upon goals and implement them given the nature of our developer
community (global, some real busy this week, some novice some
experienced, etc.).  I think the idea of making it easy for developers
to reject broken or problem packages would be an efficient way to
manage the goals for new releases without resorting to Brian's desire
for "more authority" and Ian's move to mv X11R6.  In short, I'd rather
formalize the package rejection/approval (wrt the next stable) process
in a manner that preserves the integrity of developers without adding
heirarchies and managers (which I believe would be unworkable anyway).

I now think the best way to accomplish my goal here is to simply add
an optional pseudo-header (Severity:) to the bug reporting system.
With this extra accounting it will be easier to spot packages with
critical bugs that can't be included with the next "stable".

-- 
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