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]

About organization (long)



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

This is a bit long, but I didn't want to split it up in
many letters. Sorry.

The goals of Debian

	We should definitely agree on what the overall goals and
	their relative importance for Debian are. My suggestions,
	in order of importance:

	1. The main distribution is free.

	   We more or less have this now, but we need to keep it
	   that way. (Free as in freedom, but also as in gratis:
	   there must not be any inherent requirement to pay
	   to use or distribute Debian.)
	
	2. The distribution is secure.
	
	   Security is absolutely necessary for every system
	   that is on the net, and most computers are. It is
	   OK for someone to configure his system to have less
	   security, but Debian should ship with high security.
	
	3. Installation in all common scenarios is easy.
	
	   CD-ROM, hard disk, floppies, ftp, NFS, etc. One system
	   or hundreds of systems. Novice or expert.
	   
	   This needs quite a bit of work.
	
	4. Bugs in a release are few and fixed quickly. 
	
	   Packaging and other Debian specific problems should
	   be fixed within X weeks. Upstream bugs should be
	   verified and forwarded within X weeks.
	   
	   This can't always be done, since sometimes maintainers
	   just don't have the time. But we can then maybe find
	   someone to make a non-maintainer release.
	   
	5. Upstream versions are followed closely.
	
	   It should never take more than Y weeks before
	   a Debian package is upgraded after the upstream
	   version is released.
	   
	   This is also a problem when maintainers don't have the
	   time. It may sometimes be necessary to have someone
	   else take over the package, at least temporarily. We
	   may need more maintainers, and a general lack of
	   ego to make sure this happens smoothly.
	   
	6. Administration is easy both for novices and experienced admins.
	
	   Ideally, novices who just want to use Linux
	   should not have to worry about administering their
	   machine. Packages should install with such defaults
	   that everything just works, but without compromising
	   security. This is not possible for all packages,
	   but the amount of necessary administration should
	   be small, and there should be easy tools for doing
	   typical tasks.
	   
	   At the same time, experienced admins should not be
	   forced to use Debian specific tools. They must be
	   able to do things on Debian the same way they do
	   things on other systems. This makes it easier to
	   integrate Debian systems into a heterogenous network.
	
	7. Releases happen regularly and on time.
	
	   This has always been our big problem. We'll have to
	   work hard to improve it.
	   
	This is a volunteer organization, and there is no way to
	enforce anything. And indeed, it should not be catastrophic
	if someone takes a little long to respond to a bug report.
	We need to maintain a spirit of co-operation and goodwill
	that allows us to help each other, when necessary.
	
Releases: to make, or not to make?

	Our packaging tools make it very easy to upgrade
	incrementally. Sometimes this makes the need for
	releases unclear.
	
	Many people, including many long time Linux users,
	perceive the whole Linux world to be very chaotic. All
	parts are developed indendently, so you have to keep
	track of everything.  This is a lot of work, and it
	makes it really painful to make decisions about when to
	upgrade: if I upgrade the kernel, will everything still
	work? Most potential Linux do not have the time to follow
	all the Linux mailing lists and newsgroups. Administering
	Linux shouldn't have to be a full time job.
	
	The Linux distributions aim to make this easier. The
	distribution developers keep track of what software you
	need, and which versions work together. When they have
	a collection of software that forms a working whole, they
	make a release. Users then only need to track the releases
	of their distribution of choice.
	
	If Debian does not have releases, how are users supposed to
	know when it is safe to upgrade, without spending a lot of
	time reading debian-devel?
	
	We absolutely must have a release.

Criteria for making a release

	We should continue to make a list of specific goals
	for each release, and make the release once those
	goals have been reached. Here are the general goals
	each release should satisfy:

	1. No known security holes.
	
	2. All critical bugs are closed.
	
	3. All major packages are current with upstream versions.
	
Leadership

	I'm not very attracted to hierarchies, but I think Debian
	might need a little more than what we have now. I'm
	not very good with organizing people, but perhaps we
	should have a few named persons with defined areas
	of responsibility, in addition to having one Leader.
	
	Something like:
	
	* Leader (Bruce)
	
		Overall leadership of the project. Keeps track
		of everything, has final say in all matters. Tries
		to keep everyone else from killing each other.
		
	* Chief of Security (?)
	
		Makes decisions about security issues, except when
		overridden by the Leader. Should be suitably paranoid
		and have experience with Unix security. Does not
		have responsibility to actually find or fix bugs.
		
	* Nudge (Brian?)
	
		Makes decisions about the specific goals of each
		release. Keeps track of what still needs to be done,
		and who is doing it.

	* Politician (Ian?)
	
		Makes decisions about other policy issues,
		except those about security and release, such
		as packaging. Maintains policy.sgml.
		
	I don't think we can live with a strict hierarchy, so all
	these people need to work together. Decisions should be
	based on consensus.
	
	There's loads of other important jobs, such as maintaining
	the ftp site, mailing lists, and so on. I don't know if we
	need to have everyone on the board.

	This hierarchy would have four levels:
	
	1. The Leader
	
	2. The rest of the board
	
	3. The rest of the developers.
	
	4. Everyone else.
	
	Unlike various traditional hierarchies, everyone is important,
	and everyone gets to say what they think. The Leader and the
	board of directors make the decisions. If everyone else loses
	confidence in them, we'll have to deal with it somehow.
	
	I don't know how this board of directors should relate to
	Software for Public Interest.
	
	Comments?


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