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]

Modest proposal for successful releases

One thing that the discussions about releases has made very clear is that
it is more than a little important that be provide releases that can be
installed without the uglyness of mismatched dependencies that cause
dselect to fail misserably. That it is detrimental to Debians public
perception to provide a release with broken packages. And, on this last
release, that the release gets made without adequate testing.
My partner works for PC Docs here in Tallahassee, in their QA department,
and the problems at work that she describes are almost identical to the
problems we are dealing with here. 

1. The release date is set before development begins.
2. Development continues at a rapid pace, right up to the release date.
3. QA recieves the "final" version for testing some small number of days
either before or after the release date, forcing the product out the door
with non-trivial bugs remaining in the system.

This corporate entity is having no more luck resolving these problems with
"management" techniques than we are, mainly because they are
unwilling/unable to change the above three issues.

I have been thinking about this for some time, and have a modest proposal
which doesn't involve eating our young.

First: Put less change into the release goals. A simpler set of goals
takes less time for development and provides more space for testing.

Second: Set an "internal" release date far in advance of the "public"
release. This will let developers know that they must meet an earlier
target and so, bump their schedules to succeed.

Third: Cultivate a set of users, as beta test sites, who span the range of
"strange" machines and "difficult" system configurations, who will be
willing to "fully" test the installation of the new release.

The current list of goals could spin out into 6-12 months of work and can
only lead to failure to meet goals. 
Until very recently we have only begun discussing the release after the
proposed release date has already passed.
We currently have no testing groups, either official or unofficial.

With this in mind, here is my proposal:

1. Move all source packages to the new source format.
	a. Shared libraries should provide .shlibs files
	b. Convert remaining a.out packages
	c. Fix "installed size" entries in packages

2. Re-structure archive sections
	a. Move all shared libraries into "libs"
	b. Move interperters out of "devel"

3. Pick one or two major areas of improvement to complete.
	a. Shadow password support
	b. Impliment the new web server standard
	c. Multi-thread support in objective-c and the general policy
	d. Impliment the new startup message standard

4. Fix all "critical" bugs

5. Fix as many other bugs as possible in the remaining time.

6. This has nothing to do with a particular release, but should be an
ongoing effort in any case:
Identify and monitor progress on long term projects
	a. Dselect interface problems
	b. Comprehensive config tools
	c. ...your grand idea goes here...

The current time line published by Brian is still possible if we keep it
simple and don't try to do everything on the next release.
We still have several weeks left to solidify our goals (plenty of time,
even for this group) which gives us a month to create new bugs before the
freeze and a month to find and fix them.
We only need to set our goals at a level where accomplishment is possible,
allow adequate time for testing, and we have the potential to put out our
first "clean" release.

Comments?

Dwarf

------------                                          --------------

aka   Dale Scheetz                   Phone:   1 (904) 656-9769
      Flexible Software              11000 McCrackin Road
      e-mail:  dwarf@polaris.net     Tallahassee, FL  32308

------------ If you don't see what you want, just ask --------------



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