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

Responses from a semi-disappeared DPL



Hey *,

I thought it might be interesting to have the perspective of an ex-DPL
on some of the questions that have been raised. FWIW, etc. (For people
who don't know me, I was DPL in 2006 and release manager from around
2000-2004, among other things)

On Tue, Mar 16, 2010 at 08:30:03AM +0100, Gerfried Fuchs wrote:
>  I have a question to the candidates: History has shown that DPLs more
> or less disappear not too long after their period or at least reduce
> their visible efforts immensly.

So one way of looking at this is not so much as "disappearing" as
"graduating" -- you can't really stay as DPL for very long, and on a
personal level, and after you've finished, you naturally want to move
on to new and even more exciting things. A Daily WTF article from a
couple of years ago talks about this sort of thing in relation to
jobs, but I tend to think it applies here too:

http://thedailywtf.com/Articles/Up-or-Out-Solving-the-IT-Turnover-Crisis.aspx

One way to "graduate" from a role like DPL and still be obviously
involved in Debian is taking on an old-timer advisory role -- like the
tech ctte or SPI or release wizard. There aren't that many of those
roles, though. The other alternative is to start working on something
else interesting more or less from scratch, and how much that involves
Debian depends a bit on how involved new projects are with Debian in
general.

For me, I've been following -devel, -project and -vote via the web
archives for the past year and a bit, and so far what's going on
mostly just doesn't match the stuff I'm interested in. *shrug* It
happens.

There's also the question of how welcome ex-DPLs actually are. Sitting
in a role like that in Debian attracts a lot of internal criticism,
either because you're doing things or because you're not, and that
criticism tends to linger around. And from the other side, once you're
out of a role like DPL, someone else will have taken it up and be
promoting their own views and projects, which is harder if you've got
to find respectful ways to disagree with ex-luminaries who liked doing
things the way they were done back in the good ol' days.

On Sun, Mar 14, 2010 at 02:40:32AM +0000, Dmitrijs Ledkovs wrote:
> Sometimes technical Debian discussions (mailing lists, bug reports,
> blog posts, etc.) become personal flame-wars.
> Do you think current frequency/amount of heated discussions is
> acceptable for the Debian project?
> What would you do to reduce those?

In some respects, I tend to think the focus on "heated discussions" is
a bit misplaced. Heated discussions can be great; entertaining to
watch, fun to be involved in, and ultimately advancing important
issues. And if you're too afraid to have them, you end up avoiding
addressing those important issues and going nowhere.

Getting heated disagreements to a successful resolution -- and ideally
something approaching a consensus is much more important.

The downside is that "heated" often equates to people ending up
feeling like their ideas aren't respected, or worse that they aren't
even respected as a person. And there's no point talking or helping
people when you don't get no respect.

On Fri, Mar 12, 2010 at 01:12:57AM +0100, Joerg Jaspert wrote:
> Do you plan on taking on a "2IC" or a team?
> If so: Who? And why this/those?

That was one of the things that having Steve as my 2IC was meant to
help with -- by coming a very close second he'd already demonstrated
that a bunch of developers would trust him more than me to handle
problems that came up, and having him as 2IC gave them someone else to
contact should that come up. That might not have worked if we'd felt
we couldn't get along, or if he wasn't willing to stand up to me while
serving "at my pleasure" so to speak, but fortunately those mostly
weren't a problem either.

The 2IC thing was meant to be about trying to actually get along with
the people who disagree with you; not so much about finding people who
agree with you and ganging up on the people who don't. I guess I'd
contend that that's the only way of showing respect -- if you only get
along with people as long as they completely agree with you, that's
doesn't seem very respectful of them.

On Sun, Mar 14, 2010 at 02:44:15PM -0700, Russ Allbery wrote:
> Releasing is regularly the hardest thing that Debian does, not just
> technically but also socially.  [...]
>
> Do you have any ideas how, as DPL, you would (or even could) address this?

I'd contend the most valuable thing the RM or release team can have is
respect; if people respect the release team, then their predictions of
freeze and release dates will be listened to, stabilisation and bug
fixes get prioritised, and the dates become (more or less)
self-fulfilling prophecies. On the other hand if they're ignored, bugs
accumulate, people don't bother fixing them because they don't think
the release is near, and shockingly the release doesn't get any
closer.

Maintaining that respect is very difficult: there are a constant bevy
of problems that need to be tracked, prioritised and dealt with, a
near constant chorus of complaints about not knowing enough about
what's going on, and ultimately not a great deal of support available.

OTOH, attacking the release team can get plenty of support: the
release team is nominally the "elite" within the project, so criticism
is (justifiably) one of the cherished democratic freedoms within the
project. Unfortunately, it's cherished by everyone -- which can easily
mean that it fairly quickly becomes everyone versus the release
manager. It's much easier for the DPL to deal with a conflict by
saying "Dear RM, can you provide an updated status report?" than it is
to tell a random developer "Please stop asking the RM what's going on,
it's interfering with the release."

It's not an easy job for the release manager/release team to maintain
respect even without that, of course; I'd contend the "we'll
synchronise with Ubuntu" announcement didn't help for example. But
it's a hard job. I'd say a lack of support, or equivalently,
sufficient opposition, can make it impossible.

> I'm personally the most concerned with the social issues.  A delayed
> release can be frustrating but doesn't have that much negative impact,

A delayed release has a huge negative impact on whether people will
trust your freeze/release predictions in future. The technical and
social issues are pretty entangled in at least that sense.

Cheers,
aj

-- 
Anthony Towns <aj@erisian.com.au>


Reply to: