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)

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

I reply to and quote Brian C. White. Since there are so many
different points, I've added a clarifying note to each quote
(this allowed me to reduce the amount of quoting). I hope I
didn't misunderstood anything while editing. (I should learn
to write shorter rants. :)

About only accepting bug fixes into frozen:
> There is also the case of dealing with new code.  If a new upload
> is a new upstream version that contains new features as well as
> fixes old bugs, what happens?

If the bugs can be fixed without upgrading to a new upstream version,
they should be (possibly by finding someone to do a non-maintainer
release, if the primary Debian maintainer doesn't have the time).
If upgrading to a new upstream version is necessary, then either
accept the bugs or test the new version thoroughly.

About release schedules:
> I believe that the 3-month goal is achievable.

I think so too, but not the way we've been doing it so far.
However, I'd rather stress reaching goals than reaching time
tables, and then work on setting such goals that can be done
in three months.

About mailing lists, and having separate policy and technical lists:
> Of course, the problem with new mailing lists is that it doesn't
> help anything if everybody has to subscribe to all of them.

I suspect most people won't subscribe to both lists, especially the
policy one. I'd suggest the following procedure:

	debian-devel-policy would discuss things freely
	
	when some kind of consensus is reached, the BoD makes sure 
	someone writes down a concrete proposal for the new policy
	
	this proposal is announced on debian-devel-announce, and
	comments are made to the editor of the proposal, or on
	debian-devel-policy
	
	proposal is modified based on comments

Repeat up to three times, and have the BoD make and announce a
formal decision if they accept the final draft. This procedure
would mean that most people wouldn't need to follow the
discussions on debian-devel-policy, but would still be able to
comment on proposals before they're decided on.

On dividing:
>   project leader
>   testing manager
>   policy manager
>   security manager

I assume the last three won't need to be on the BoD. It's probably
not a good idea to collect volunteers yet, until the BoD starts
working and there is a more complete proposal on how to divide
work from now on.

> You CANNOT give responsibility without authority and expect things to 
> work out.

I agree.

-- 
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: pgpNi2fhmJfk8.pgp
Description: PGP signature