[darcs-users] On Release Management

[Eric Kow]

Hi everybody,

Finally got a chance to read this and think about this thread a bit.

Context
----------------------------------------------------------------------
Darcs 2.4 and 2.5 had painful release processes with protracted delays.
Reflecting on his RM experience, Reinier came up with some suggestions
on how to improve the release process.  Stephen, Matthias and others
followed up with insights of their own.

My understanding is that there are two main things we need to figure out
in this thread

I.  How can we improve the release process? In particular, how do we
    get the Darcs team more focused on the release?

II. Do we need to change Darcs development itself for less painful
    releases (fewer last minute bugs). How?

It sounds like the ultimate responsibility for deciding what to do
with the first discussion lies in Florent and Ganesh as Release
Managers.  I tend to recommend consensus as the core decision-making
tool, but of course deciding how to decide is up to them.

The second discussion looks like a team-wide affair. It also sounds
like things that are harder to reach a consensus on, partly because of
all the variables we have to consider.  Maybe we need to think a bit,
try some experiments, and discuss at a leisurely pace.

Even though the two discussions are related, I suggest we focus on
the first one in this thread and explore the second one separately.

I. Release process (focusing more on releases)
----------------------------------------------------------------------
Stephen had a nice insight that the deeper problem may be more Q&A
during development (II) than the release process (I). While this may be
true, I think we could stand to work on some aspects of the process, for
example, the kinds of things that lead to bugs we discover not being
fixed for a long time.  Maybe it goes back to the question of how to get
developers working more in concert with the RM during release time.

Suggestion 1: feature-based releases
====================================
> So instead of saying that we release darcs 2.X at time Y with whatever
> features are ready by then, we make a realistic list of features that
> should be in a new darcs release well in advance. We could make a
> list of features for the next release immediately after every minor
> release. I hope that if we have a concrete idea of what the next darcs
> release will look like, we will be more focused to deliver it.

Comments so far:

* Stephen: worth trying, but see #1
* Guillaume: time-based releases tend to work better for projects
  like darcs (the heartbeat argument)

I tend to believe the heartbeat argument. Having a fixed release
calendar that's common knowledge helps darcs developers to coordinate
and helps the ecosystem to synch with darcs development.  The kinds of
benefits are a bit tricky to pin down, so I'm glad Guillaume pointed
to some more work on it.

One particular benefit I can think of (having failed to RTFT) is that it
adds a sort of sense of urgency (consider the hunk editor discussion for
example: it was partly possible to have this discussion because we
needed it to get done with in time for release).  I'm concerned that
returning to feature based releases will bring back a certain
sleepiness/stagnation in Darcs development.

Also: Guillaume observed that for time-based releases to work well, new
features need to be rolled back easily.  Taking NewSet as an example,
would we agree that rolling back this new feature (better performance)
was hard because it was invasive?  Or is there a better reason?
If it's like invasiveness, what I figure is that maybe a nice clean
library will help (GH) or maybe we need to raise our coding standards,
BUT if these things happen, they probably won't happen for a very long
time. So in the short term at least, we may have to resign ourselves to
Stephen's other suggestion, lowered expectations.  If we've got more
painful surgery (deep refactors?) in store for Darcs 2.8, we may want to
anticipate a much longer release cycle. Lowered expectations isn't
necessarily a negative thing, by the way.  For example, we could say
that it was strategically important for us to get that performance
release out the door, that the pain was worth it.

Note: maybe setting *realistic* release goals as Reinier suggested will
prevent the stagnation problem in feature-based releases?

Suggestion 2: HEAD for releases
===============================
Matthias (kili) wrote:

> Why use a release branch at all, *before* the release happens? It
> may sound strange, but I'm serious

If I understand correctly, the idea here is to use HEAD for the release
process itself and only to cut the major branch after the release goes
out

Comments so far:

 * Zooko seems to have suggested this independently
 * Reinier finds it elegant
 * Simon Michael +1s
 * Ganesh: sceptical about effectiveness of this tactic

I think it could be worth trying.  This is the kind of situation where
predictions about how things it work out may be more based on
speculation than anything else (?).  If that's the case, perhaps the
best attitude to adopt is a sort of willingness to experiment, accepting
the possibility of things working out badly.

Fuzzy History: I don't know Darcs history from before 2005, but when I
first joined, we were working with parallel stable and unstable branches
each with their own maintainer.  Releases would be based on stable when
the stable maintainer felt it was time.  Around the Darcs 2.0 release
(2008-04), we switched to a one-branch model because the unstable
maintainer at the time [me] could not keep up with the Darcs 2 changes
and eventually stepped down. In late 2008, we reintroduced the stable
branch as a way to relieve pressure on David. Finally, during the
transition to the new team, Petr (?) introduced release branches.

I think four things have changed since Petr introduced release
branches.

- core team maintains HEAD, not one person (not sure if this came
  before or after, but it may be a factor to consider)
- more relaxed push rules (trivial or peripheral things need not
  be reviewed)
- core team pushes directly to release branch, with policy about
  what to push
  http://lists.osuosl.org/pipermail/darcs-users/2010-June/024284.html
- better infrastructure/automation for doing releases (thank you
  Petr and Reinier?)

Maybe these things make the conditions for release on HEAD a bit
better?

Petr wrote:
> First, I could pick what goes into release and what does not, after
> the freeze point, without imposing that every change to HEAD is reviewed
> by the RM.

The stable branch workflow had a similar cherry-pick property.  Anyway,
this may be addressed by the new policy (1) saying to push release-ready
stuff directly to release branch and (2) defining release-ready.

> Another is that I needed to do some
> packaging and such changes that I didn't want to wait for review -- I
> would do them on the release branch myself in the RM capacity.

Fixed by whitelisting of trivial and peripheral changes?

> I believe under this scheme of things, the RM needs to be able and
> willing to fix RC bugs himself. It is of course the most frustrating
> part of being the RM: you need to get out the release and most of the
> team is not extremely interested in fixing those blockers for you.

Sounds like an argument for release-on-HEAD approach. Alternatively,
maybe RM'ing needs more aggressive managing (hence Petr's suggestion
of splitting RM into tech/managerial?)

II. Improving darcs development
----------------------------------------------------------------------
I'll just list what looks like the two key discussions from this thread,
basically suggestions by Stephen that we could either go with lower
expectations for stability, or put a lot more emphasis on it in two ways.
I think it might be good to make progress on the easier discussion above
and talk about the harder stuff below separately.

* Suggestion 3: emphasise stability, plan more
* Suggestion 4: raise the bar on new code

Thanks,

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
For a faster response, try +44 (0)1273 64 2905 or
xmpp:kowey at jabber.fr (Jabber or Google Talk only)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20101204/ebd2dbe3/attachment.pgp>