[darcs-users] On Release Management

Reinier Lamers tux_rocker at reinier.de
Thu Nov 11 21:07:03 UTC 2010


2010/11/8 Matthias Kilian <kili at outback.escape.de>:
> Hi,
>
> On Sun, Nov 07, 2010 at 03:23:35PM +0100, Reinier Lamers wrote:
> [2.4 and 2.5 pain snipped]
>> Such issues delaying the release are a real problem. The longer a release
>> branch is separated, the harder it will be to merge fixes from HEAD into the
>> release branch and to merge the tags from the release branch back into HEAD.
>
> Why use a release branch at all, *before* the release happens? It
> may sound strange, but I'm serious. [Note that what I'm suggesting
> here and below is backed on how the OpenBSD release process is done;
> it may or may not work for darcs; it depends on the size of the
> project (darcs is much smaller than a whole operating system) but
> also on the amount of developers and users willing to test stuff
> (probably also smaller then for OpenBSD). And please note that I'm
> *not* a darcs developer, although I'm at least testing darcs-HEAD
> from time to time]

We use a release branch so that big changes can continue to happen in
HEAD while we're stabilizing the release. So if we wouldn't branch, no
big changes could happen during the weeks before the release. That
would be a way to keep people focused on the release.

I have to say that I find this release process without branching
beautiful. It could be frustrating however if the release process gets
delayed nevertheless and there's no place to work on new features, not
even if you aren't involved in solving the release problems.

>> We hope to address the problem of lots of regressions being found by doing
>> alpha releases whenever big changes are merged into HEAD. But the problem of
>> release-critical bugs not being picked up remains.
>
> Big changes should stop some time before the late release cycle
> happens.  This should be announced, so people who are not involved
> in the development (and not running HEAD all the time) have a chance
> to give HEAD a try, if they're brave enough.

If we want non-devs to try out HEAD, we'd have to make HEAD more
accessible. We don't have nightly builds now (though we tried to make
them from the buildbot afaik).

> Of course this may fail, in case only developers are running HEAD
> on a daily base. If this happens, it means that there are too few
> developers (or/and people running HEAD). Which in turn means that
> there are too many big changes causing regressions which scares
> people to test HEAD frequently.

...or that HEAD is not easily accessible.

>> That means that when we are in a release cycle, the release should be the most
>> important darcs issue for all developers. When a release-critical regression
>> is discovered, it should be picked up in a couple of days, not weeks. If a
>> regression is discovered that was introduced by your code, it's time to drop
>> other darcs things you are working on and fix it right away.
>
> That would mean that changes causing regressions would just be
> rolled back from HEAD and could worked on again after the actual
> release happened.

Sometimes, those changes are so dependend-upon that rolling back would
amount to crossing out more than half of the feature list. I didn't
want to go that far.

>> Still, perhaps we can increase people's commitment to releases by making them
>> more feature-based than they are now.
>>
>> 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.
>
> That won't work. Planning ahead which features will make it into
> the next release can't work. It doesn't work for commercial projects
> (small or large ones), and it just can't work for volunteer projects
> like darcs.
>
> Suppose you're at darcs-4.2, and are planning a release for darcs-4.3
> a few months later, with some super-cool features added. What if
> those features additions just aren't finished until the release
> time for darcs-4.3?

If important features are behind schedule, the answer would be that
people working on less important features would help to make the more
important features happen. Which features are important is what would
be decided beforehand. Now of course in programming allocating more
people to a task only goes so far. If you already have the optimal
number of people assigned, yes, then the feature is not going to make
it.

> On the other hand, if you just do releases based on HEAD (which
> some slowed-done development process happening a few weeks before
> the release), you'll get what got done. It may be new features, but
> it may also be just some bug fixes or performance improvements. But
> you don't have to worry much about the quality on the release, and
> you don't have to defer the release.

Well, you will have to defer it if we discover bugs. But I suppose you
mean that the bug fixes will be immediately usable for the release,
and we wouldn't have to wait for the submitter or release manager or
another helpful soul to port it to the release branch?

>> Now I realize that these ideas conflict with the current darcs culture, and I
>> also realize that it remains to be seen if I can practice what I preach next
>> to my day job. Still I'm interested in hearing your opinions.
>
> But what *is* the current darcs culture? That's a honest question,
> because I'm a slacker and not following all the discussions here
> and all pushed patches, especially if it comes to when and how new
> features are added and when and how bugs are fixed.

The darcs culture trait that I meant here is that people usually work
on some feature in relative isolation. In the scheme I proposed,
people would be working together to make the next release happen. So
instead of just not including feature X in a release when the one
working on it says he's not going to make it, you would ask "what can
I do to get it done before the release" if feature X is important
enough.

> I don't know whether a HEAD-based release process would work for darcs,
> and huge changes would be more difficult to get in (becase they'd be
> done in small steps), but maybe it's worth a try, anyway.

I definitely find it interesting. It doesn't ask as much from the team
members as my proposal does, but it may still be a good incentive to
make people make their code release-ready in time.

Reinier


More information about the darcs-users mailing list