[darcs-users] Release Management

[Eric Kow]

Hi everybody,

As you know, there is a Darcs 2.5 planned for July.  That means we're
less than a month away from freezing (so get your patches in!)

Lately, we've been trying to recruit a new Release Manager for Darcs,
but we're having trouble finding some candidates.  I was going to post
another recruitment message, but having discussed a bit with the team
[1,2], I think we need to re-think.

Anyway, for the interested, here's my attempt at snapshotting the
the discussion.

Before I say anything else though, if you are interested in serving as
Darcs RM (regardless of whether or not you think you have the ability to
do the job), please say so.  It'll help us to figure out what to do.

What does a Release Manager do?
----------------------------------
First, some background. The current list of RM responsibilities looks
like this:

 1. Set up a freeze schedule
 2. Make freeze announcements [we have templates for this]
 3. Decide what patches go into frozen branch
 4. Keep track of the issue tracker (track the Target-X.Y bugs)
 5. Chase up on Darcs hackers to fix outstanding release critical bugs
 6. Help decide which bugs are (or are not) release critical
 7. Update the NEWS file
 8. Create the tarball
 9. Write release announcements

I say responsibilities and not jobs in the sense that the RM must make
sure that these things are done.  This may usually mean doing them
himself, but it may also mean delegating whenever appropriate.

For more details, http://wiki.darcs.net/Development/ReleaseManagement

Who has time to do Release Management?
-----------------------------------------
This is the old Day Job problem that we keep running into over and over
again.  The good news is that major releases only happen twice a year.
The bad news is that when they do happen, it can be a lot to ask for
somebody working a 40h a week job.

Also Release Managing can be boring.  Not much glory, a lot of widgets
to crank. If I had unlimited time on my hands (or better time
management, then the answer would be obvious; I'll crank the widgets and
you guys go get things done.

How can we deal with this?

1. Find somebody with more time, but who? [and some willingness to do
   a bit of widget cranking]

2. Make the job easier.

   One improvement I plan to make is to bring back the
   resolved-in-{stable,unstable} distinction on the issue
   tracker. Getting rid of it was my idea and it looks like
   it was the wrong one.  Sorry!  Reinier has pointed out that this
   distinction would help him to track of which issues are still
   outstanding for him.  'Resolved' doesn't mean anything because it
   doesn't say whether it's resolved on the release branch or not.  To
   make this work better, we should introduce a bit more automation
   updating the tracker automatically when a patch is applied to the
   release branch.

3. Distribute the load... see below

How much experience does a Release Manager need?
---------------------------------------------------
There's a fairly wide range of attitudes in the Review Team about this.

We could say that no experience is needed (the person can grow into the
job and we can provide training which will pay off over the long term).

Or we could say that actually, it's not realistic to expect the Release
Manager to be effective without being a Darcs developer (for the sake
of argument, a Review Team member).

A more middle ground position is that as a minimum you need some sort of
experience using Darcs, shell scripting but no Haskell; and that being a

How can we share the load?
--------------------------
In the discussion from Tuesday [1], Petr suggested a way of spreading
the job out throughout the team as a form of policy.

For example, instead of the RM having control over branch-2.5, we could
systematically push in any patches that has been approved for release by
two review members. (Implementation details to be decided)

Alternatively, we could have a policy which is based on the issue
tracker.  A crude version being something like, all patches that get
accepted must be tied to a Target-X.Y issue on the tracker.

One of my biggest worries about splitting up the RM role is the old
diffusion of responsibility or bystander effect problems [3,4], but
surely there must be some way of figuring out which bits of the job need
to have a single person associated with them and which bits we can
spread out?

Reinier has observed that the bulk of the work was in

1. Keeping track of issues
2. Getting patches for all issues
3. Maintaining a coherent release branch

Reinier thinks that #1 and #2 cannot be split up or delegated.  You need
somebody to be responsible. #3 on the other hand could conceivably be
spread out to the Review Team (perhaps as Petr suggests).

The current status
------------------
Unless somebody volunteers (or suggests something brilliant), I think
the current plan (listening to Petr and Reinier) is

- Reinier continues RM'ing for the Darcs 2.5 release

- We experiment with a more distributed approach to taking care of
  the release branch

- After Darcs 2.5, Reinier tells us about what worked/did not work,
  and we look for another RM again.

It could be a good idea for us to learn from other open source
projects too.

So that's the current status as I understand it.  Please shout if I've
misrepresented anybody's position and if in particular, you think you
might be interested in the job.  There may be widgets to crank, but the
end result is that exciting new Darcs release...

Eric


[1] http://irclog.perlgeek.de/darcs/2010-06-08#i_2415190
[2] http://irclog.perlgeek.de/darcs/2010-06-09#i_2418799
[3] http://en.wikipedia.org/wiki/Diffusion_of_responsibility
[4] http://en.wikipedia.org/wiki/Bystander_effect

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20100610/d30802b5/attachment.pgp>