Re: Debian doesn't have to be slower than time.
> > 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!"
>
> Not me, I agree with you.
>
> > 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.
>
> I don't think that absentee maintainers are adding any strength to
> Debian at all though. Anything we can do to either motivate them or
> get rid of them is a good thing. (Yes, this means that if anyone is
> thinking about standing for DPL and has some concrete proposal for
> coming up with a process to identify these people and kick them out of
> Debian, you'll probably get my vote.)
Well said.
We can't have people around that don't do their share, but on the other
hand it's hard to find something to point these people at and say, "look
here... this is how it's _supposed_ to be done." Lead by example, provide
guidance, feedback, correction, push, (in that order) and then, finally, can
'em. You want people to learn, but we need to help them, too. Not every-
body is a natural.
> > 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.
>
> Yes let's not lose sight of that. A lot of those people have been
> working on RC bugs all weekend and doing a fine job.
>
> > 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.
>
> We don't currently have sufficient information to be able to revert
> changes to base packages always, and it can sometimes be very hard to do
> so, and a great deal of the time RC bugs in base packages can't be fixed
> by a reversion to any known version. However, we currently have *3* RC
> bugs in base (and some 30 in standard), so that is not currently a big
> deal.
It's by no means perfect, I agree. You could potentially find an RC bug
that is retroactive all the way to the last "stable" release and then
you're stuck. That should be the rare case, though. If you can catch
80% of the problems, then we're kilometers (miles for you Yanks :-) ahead
of where we are today.
> Dropping buggy packages proactively, if that's what it takes to motivate
> people, seems like a good idea. It will lead to even more bug severity
> inflation though. Maybe it's not something to worry about right now,
> since that's about to start happening anyway in the context of the
> freeze.
I dunno. If a maintainer is around, then they have plenty of time to
examine the bug and downgrade its severity if they see fit. Either way,
it reduces the number of RC bugs. An RC bug by definition means that
the distribution is better off without that package than with that bug.
If it's that serious, then presumably it's not being used as it is
anyway.
That is really an easy issue, i think. If we have a rough concensus
that this is the right thing to do, then it's easy to implement and have
it happen.
The hard thing for leaders would be these items:
- 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.
There are no computer programs to make these happen. They require a
strong jaw ('cause you're gonna take some hits) and an even hand. They
are, really, the qualities of a leader.
For the rest of us, I think the most importand things to do are:
- 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?
- 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.
If you like what you're doing, then you'll do it better. I wonder how
many people would say that Debian is as much fun as it was when they
first joined. I know I feel generally beaten up and suffocated by
some of what has happened in the 6 years since I first joined the project.
Brian
( bcwhite@pobox.com )
-------------------------------------------------------------------------------
Tired of spam? See what you can do to fight it at: http://www.cauce.org/
Reply to: