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
signature.asc
Description: Digital signature
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
