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]

Debian: some opinion on our problems



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

Since the beginning of this year, I have been working full time
again, and have had little time for hobbies. My incoming mail
folders are growing at an alarming rate. Since Debian seems to be
having problems, I'm taking today off to deal with at least the
Debian issues. (The wonders of not having fixed work hours.)
Yes, I'm going to inflict yet another rant on you.


It seems to me our problem is that the Debian distribution is a
big pile of buggy packages that no-one cares enough about to fix.



That was intentionally provocative. Now that I have your
attention, I'll elaborate. I don't wish to attack anyone
personally, and I'm not pointing fingers at anyone. The
distribution is produced by the volunteer developer community,
and if there are problems, we're _all_ at fault.

While we, as the people in the Debian project, may think we have
many problems, we really only do have one: the distribution
doesn't work well enough. This is the only problem we need to
care about. Everything else is unimportant in comparison.

The low quality of the distribution is itself a symptom of many
underlying, interacting problems, the most important ones being:

	* Little organization.
	
	* No quality assurance.
	
	* Too rapid growth.
	
	* Too much ego.

About organization: We have a hundred or two hundred volunteers.
Everyone does their own little thing, and there is not very
much coordination. The result: Everyone works on packaging new
stuff, since no-one is directing work on testing, documentation,
or other areas that need work. Important problems go unsolved
for months, because everyone expects someone else to tackle them.
For example, improving dselect.

What little organization we have is also not very good at
deciding, implementing, and sticking to policy. Discussions are
endless, decisions are not communicated effectively, and are
questioned repeatedly. Witness the web standard, place holder
directories in /usr/local/lib, dependencies on elf-x11r6lib (now
xlib6) instead of X11R6 and other bogus stuff, documentation
in HTML, to name a few. It's not enough to decide on policy. It
needs to be followed as well. Questioning it is OK, but not if
it happens every week, and with the same arguments each time.

About quality assurance: In truth, we have none. The only similar
thing is our expectation that each maintainer makes sure his
package works, and that users will complain if it doesn't. It
should be obvious by now that we need something much better.

About rapid growth: The problems were manageable when there were
only some dozens of developers and packages. It's now trivial
to create a Debian package, and the number of new packages
and developers is a problem. New developers will always make
mistakes, and will require some education. This takes away
energy from other tasks. Worse, the education needs to be done
by people who have been developers for a long time, because
newbies educating newbies results in problems, misunderstandings,
and confusion.  Even though we have a huge number of developers,
there's more and more work for a small number of key persons.
We are heading towards that critical mass which causes a project
to collapse.

About ego: There's way too much flaming on debian-devel and
debian-private. People too easily take arguments, and bug
reports, personally.  We need to be able to disagree without
getting annoyed, or else we won't be able to work together.


I don't have any solutions to these problems, at least nothing
I can promise will work. There is no silver bullet, no way to
guarantee quality. The only known ways are to either employ
excellent people, or to organize work in a way that usually
avoids problems. We need to do the latter, or kick out everyone
who isn't a linus torvalds.

I do have some recommendations for your consideration (some
of these may sound familiar, since they're based on earlier
discussions):

	1. Elect the Board of Directors soon. Have them re-organize
	   the project in a suitable way. For example, identify
	   important tasks that need to be done, and get people
	   to commit to those tasks. Establish a chain of command
	   that is palatable to hackers. Have backups for every
	   key person.
	   
	2. Create a big enough quality assurance group to approve
	   releases, including fixes to stable.  The members need
	   enough hardware and time to do different kinds of
	   installations. No package should be put into stable
	   until it has been tested. QA should also approve
	   all new packages, except those in experimental.
	   At the same time, QA shouldn't become a bottleneck.
	   
	   Hackdom is a meritocracy, but QA work is rarely a merit.
	   We'll have to give the QA people fame, glory, and respect.
	   We'll also have to make sure getting rejected by QA won't
	   cause flames.
	   
	3. Define minimum response times for different types of
	   bug reports, and establish a backup procedure when
	   that time is not met. Note that a response doesn't
	   need to be a fix: even just an note that the developer
	   can reproducte the bug may be enough in some cases.
	   
	   For security problems, I'd suggest 24 hours for a
	   confirmation, and 96 hours for workaround (possibly
	   just disabling the problematic part), or withdrawal
	   of package from distribution until fix is available.
	
	4. Have a couple of jovial persons tone down heated
	   discussions on the Debian lists. I don't know how this
	   would be done.
	   
	5. Add a severity field to the bug system. That would allow 
	   us to keep better track of important things.
	   
	6. Keep goals realistic. Too many things we want to do
	   require large amounts of work we are unable to do in
	   a timely fashion. For example, i18n. We try to take
	   many large steps, and stumble a lot.  Let's take
	   many small ones instead.
	   
	7. Stay away from the bleeding edge. We don't need to
	   have the latest version of every piece of software,
	   unless it fixes a security hole.  We need to have
	   stuff that works. For example, let's forget about
	   libc6 until it has actually been released.
	   
	8. Make sure no-one has too many responsibilities.
	
	9. Make things fun again.

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