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: Why were there many releases after rex was frozen

[ Please don't Cc: me when replying to my message on a mailing list. ]

Kevin Dalley:
> Fixes for minor bugs should either be made before the freeze date or
> wait until the next release.  Forcing dozens of minor bug fixes into a
> release is likely to destabilize it.

Does anyone have any logs for what changes happened during the
freeze, and preferably the relevant .changes files as well?

I'm not sure I agree that we shouldn't fix minor bugs. However,
we might want to make a rule that during the final seven days of
the freeze only critical bugs may be fixed in frozen. If anything
in frozen changes, the seven day period starts again.

The development cycle would then be:

	* experimental: if it is likely to cause trouble
	* unstable: anything goes, as long as it probably works
	* unstable if frozen four weeks before release
	* first three weeks of frozen: only bug fixes (no new
	  packages, no new versions)
	* last week of frozen: only fixes to critical bugs; if
	  any are needed, however slight, the last week starts again
	* release is made

Other values for three and one week may be better, of course.
I don't understand project management or software engineering
well enough to know.

Also, we might want to have N reports that the final frozen has
been installed successfully from scratch, in various kinds of
configurations, and M reports that it has been upgraded from
the previous release, also for various kinds of configurations.
This needs to be organized well in advance, so that people can
arrange schedules and downloads. Suitable values for N and M
might be 5.

This is a lot of work, of course. It might help us avoid a few
problems, however, and give some credibility for any claims
about quality that we may want to make.

(I'm not suggesting our quality is low, but a documented,
systematic, well-known, and good process tends to raise quality
as well.)

-- 
Please read <http://www.iki.fi/liw/mail-to-lasu.html> before mailing me.
Please don't Cc: me when replying to my message on a mailing list.

Attachment: pgpM_fi4isuyV.pgp
Description: PGP signature