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)



Dan Stromberg :

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

some points:
1) IMO we need two types of testing/quality assurance :
   a) for the whole distribution
   b) for single packages

2) some people are talking about continuous releases. IMO the current
   unstable/stable (/frozen) method should be changed as far as possible
   to a  released (=stable)/tested (new)/untested mechanism. 

   somebody should write a test report program, that can be feeded with
   test reports ("ok", "bugs" (more result levels ?)) by email, and that
   can move a package from untested to tested if (conditions : time for
   testing, number of "ok"'s etc). and a samm script as frontend would
   be nice (something like the bug tool).

   you should only have an option to "take back" a tested version and
   put it back into untested/unstable, and recovering the last tested
   version.

3) i like major releases, but don't push developers to get the latest
   version of their programsm ready for the next release. a release
   should take the programs already tested and not hurry to get
   everything tested for releasing. the goal "good. tested distribution"
   is more important than being "up to date/always the newest version".

4) it doesn't make any sence if this discussion is held by a large group
   of developers. a small workinggroup should do the job and start now.
   a small group (maybe only one to three developers) can quickly find
   solutions. 

that's why we have eleceted a BoD : they can make the necessary
decisions fast, put a group of voluntary developers in place to do the
job. IMO the BoD importants job is to stop never ending discussions and
decide that someone does whatever is needed. 

changes, rewrites etc. can be done later, if the result doesn't fit our
needs, but my belief in debian developers is that they will find a good
solution. and anything that might fit our needs is better than a never
ending discussion. 

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

yep. start now.

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

yes, we need practice. and i can't find any reason to wait till 1.3 is
released befor we start. 
 
yust my $0.02.

regards andreas


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