Re: Debian doesn't have to be slower than time.
> * Why does Debian take so long to release?
> * Why does it *matter* that Debian takes so long to release?
> * How do we avoid putting out buggy releases, while going faster?
> * How do we avoid running out of toy names?
> * How do we know when we've done a major-version release?
> * Why should we bother with any of this?
I must say... It's interesting to note that in the 3 years (or is it 4
now?) since I left as Release Manager, Debian has only managed one release.
People criticized me mostly for being too draconian. Perhaps they were
right, but at least things went out the door.
That's not to say that the current coordinators are doing a bad job, it's
just that their job gets bogged down with too many other things.
The basic problem everybody says is:
* We can't release with release-critical bugs.
That's a given just by its definition. The obvious question is:
Q: Why are there [still | so many] RC bugs?
to which everybody whines:
A: Because developers don't fix them.
This isn't the complete truth, though... A lot of RC bugs really aren't
such. They're just ordinary everyday bugs that are reported as RC because
that seems to be the only way some packages get their bugs fixed. Thus,
though the original answer didn't explain why many of those RC bugs got
there in the first place, the answer there is the same:
A: Because developers don't fix them.
I originally tried to tackle this problem with "nag" that would email
developers on a periodic basis to remind them that they had a commitment
they were not living up to. Some people spent more time complaining about
"nag" that it would have taken to just fix the damned things.
So, the next obvious step is:
Q: Why don't developers fix their bugs?
In continuing with obvious things...
A: Because they don't want to.
And there are many reasons for this. Many developers can't be bothered to
work on bugs that aren't affecting them personally. Some don't even seem
to read their bug mail. I've reported several bugs in the past that were
obviously problems upstream and yet there was never a single reply and
the report was never even forwarded to the actual developers. And then
there's the wonderfully ironic feeling that many developers (including
myself) have that "why should I hurry to fix bugs -- it's not like there's
going to be a release anytime soon".
It's things like this that drag the whole project down. There is a group
of really amazing developers in Debian; they do us, the project, and the
world proud. But they get bogged down by the beaurocracy and swept away
in the tide of apathy that comes from many of the other developers.
Where is the pride people used to show at having bug-free packages? Where
is the eagerness that people used to have for improving their packages?
I'll bet you dollars to doughnuts that there is a huge proportion of
developers reading my comments and thinking things like: "If you don't
like it, leave!"
And that, my friends, is _exactly_ what I'm talking about. "It's my way
or the highway." It seems we've forgotten that somebody's conflicting
opinion is a source of ideas. True strength comes from the differences,
from learning from and working with those that see things in other ways.
Many users are displeased at Debian's slow release cycle. Do you
really want them to leave, or can you find ways to accomodate them
as well such that the project is made better as a whole?
Now, it's no good complaining unless you can offer some suggestions on
how to improve things.
- Drop packages with RC bugs after a month; don't wait for a freeze. If
it's a base package or anything that simply can't be dropped, revert to
the previous version without RC bugs after a week.
- Start some kind of automatic notification of outstanding bugs. Make
sure developers understand that by submitting a package, they have
a responsibility to maintain it. With responsibility, though, needs
to come authority or it's meaningless. Don't second-guess the
maintainer if they make a decision about a bug, no matter how wrong
you personally may feel that decision is.
- Have parties. Synergy can only come when there is a high degree of
trust. Big cities should be able to put together a decent group of
people to go out for a beer some times. Get to know those around
you. Any other Debian developers in Ottawa, Ontario?
- Don't try to please everybody. Is a given RC bug really release-critical
or is it more of a "release-should" or perhaps even a "release-wish"? If
so, then forget it and move on this time. Let it get fixed in the next
release. This only works, though, if you're doing releases every 6
months or less.
- Make a decision and stick to it. If the release date comes and there
are still RC bugs, then don't allow anything to change except for the
fixing of those bugs. Don't allow any changes even if they fall under
the "release-should" category. Note: this will be hard the first time
because nobody will believe you're serious. It will be easier the
second time if you stick to your guns the first time.
- For God's sake, HAVE FUN!!! There are perhaps a few among us that Debian
makes up part of a job, but for the rest of us it is hobby. If you're
not enjoying what you're doing, then get out now and do something you do
enjoy. Life's too short.
Brian
( bcwhite@pobox.com )
-------------------------------------------------------------------------------
You may fool the whole world down the pathway of years and get pats on the
back as you pass; but your final reward will be heartaches and tears, if you've
cheated the man in the glass. ("The Man In The Glass" -- Emily Dickinson)
Reply to: