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: Quality: some thoughts on achieving it (long)

bcwhite@verisim.com:
>I have to disagree with this.  Given the large number of problems that
>1.2 caused and the possibly long period between 1.3 and 2.0, I think we
>should not shorten (and possibly extend) the development time of 1.3
>just to make sure it's in excellent working condition before release.

Guy Maor:
> You misunderstood him, Christoph.  He said that because it would take
> a long time to get 2.0 ready, (2.0 would have glibc), we should
> release 1.3 sooner.  1.3 would still be libc5 based.  We would like to
> start with glibc soon, but as soon as we do are committed to waiting a
> long time for the next stable release.

We have disagreement.  I've been part of it.

Given that bo is pretty stable, how about if we:

1) Continue discussion of a testing procedure.  There have been some
good efforts in this direction; more are needed.

2) Finalize a testing procedure that most of us can agree with, or that
the majority of BOD members agrees with.  That testing procedure should,
among other things, include definition of when things are "tested well,"
because we have a LARGE tendency to say "that's good enough" when it
isn't.

3) Put the required tools in place (if any) to start testing.  Organize
testers.

4) THEN freeze bo

5) USE the testing procedure for a while, until things are "tested well"

6) release as soon as things are Tested WELL, and not before.

I don't know that there's any reason to delay, but not delaying should
mean immediately getting started on doing a good job this time.

There's little point in making shoddy releases; it chases away users
very effectively.

We NEED PRACTICE before doing a 2.0.  2.0 is the absolute last place to
find out "oh, our procedure needed some serious work."  In fact, I'd say
that if we can't do a 1.3 well, we should probably schedule a 1.4.


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