[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

On management


it is certainly a bit too early to look back at the etch release
process, as we still haven't released yet, but I'd like to share some
thoughts on what happened. Please note that these are entirely personal

Back in September, it seemed impossible to the GNOME team to bring GNOME
2.16 into a releasable state before the planned release date. We took
then the hard decision to keep GNOME 2.14 and bring only the few parts
of 2.16 that weren't disruptive (meaning especially, no gtk+ 2.10 and no
gnome-vfs transition to dbus).

It should be obvious now that, with the delays the release is facing,
this decision was wrong. With the icon themes fixing, I think the last
showstopper for GNOME 2.16 is now fixed. Of course, at the time it
became clear it would be possible to polish 2.16 before the release, the
distribution was already frozen. The result is, we have a desktop with
less bugs, more features and speed improvements, which is almost
completely ready (apart from evince) for the upcoming stable release,
and it's not going to be shipped. Currently it is only used by a handful
of people running experimental. As GNOME 2.18 is scheduled in two
months, this means we will be lagging two versions behind upstream as
soon as we have released.

Not only did it generate more work as we had two GNOME versions to
maintain during the freeze, but it is now generating a lot of
frustration because this extra work looks like a loss of time.

It is my belief that such things could be avoided if we had proper
release management. Don't get me wrong: I'm not trying to throw stones
at the release team, especially because I couldn't have done better
myself, and because I'm partly responsible for the GNOME decision. The
release team is doing an excellent job; unfortunately this job isn't
about management, but about technical expertise. Of course this is
helping the release, but I wouldn't call it "management". Fixing RC bugs
is a thing, setting release goals and dates depending on lots of
people's work is another.

Management is quite a different job that what most of us are doing. In
the real world, a good manager is as rare a resource as a good engineer,
and you need both to make a business running. The Debian project is
currently good at attracting technically excellent people, but we also
need a few people with management skills, and currently I fail to see
what could bring them to work for the project.

As of now, I see it as a failure of the project. But this is also
nothing that can't be fixed. What do you people think could be done to
bring the skills we are lacking to the project, with its current

: :' :      We are debian.org. Lower your prices, surrender your code.
`. `'       We will add your hardware and software distinctiveness to
  `-        our own. Resistance is futile.

Reply to: