Re: Release procedure.

[Karl Fogel <kfogel@red-bean.com>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I've long been baffled that trunk work is affected by the fact that a
>> release is under way.
>
> The reason is very simple: because of a lack of resources, we can't spread
> half the resources working on a "new trunk" with the half working on
> bug-fixing on a release branch.  So we first declare a freeze, then do
> bug-fixing on the trunk (during which time, development is significantly
> slowed down), and only when the amount of bug-fixing left is expected to be
> sufficiently low, do we finally branch so as to allow people to start
> hacking again without affecting negatively the time of the release.
>
> It's a delicate balancing exercise to motivate people to do bug-fixing and
> other release-preparation work without frustrating them away.

Thanks for the explanation.

I think, though, that this is based on a fallacy about fixed
resources.  It might even be *causing* a lack of resources.

If each developer were going to do X amount of work no matter what,
and that work could either be "new trunk" or release work, then this
method would make sense.  But in practice, many of us just stop doing
anything at all during the release process.

On the other hand, if there were a release branch, those who were
going to do release bug-fixing work anyway could do it just as well on
the release branch, while others are active as usual on trunk.  (In
practice, the same people often do both, but the difference is that
they could choose what to do when, and thereby do more.)

Of course, I understand there's some overhead: in such a system, when
you find a bug on the release branch, the usual procedure is to fix it
on trunk, then port the fix over to the release branch.  Ongoing trunk
work can sometimes interfere with that porting, so the system isn't
completely costless.

But other projects I work on use it, and my impression (based on a lot
of experience, at this point) is that it results in

   a) more development activity overall, and
   b) not noticeably less release work.

Whereas right now, when Emacs trunk is frozen, I am frozen (except
when a bug comes up in a package I maintain, of course).  I don't have
time to work on the release, though I occasionally have time to make
contributions that aren't urgent enough to go into a releasable line.
Until we finish the release, those contributions are held up.  It
seems I'm not the only person in this situation.

It's not like fungible resources being divvied up among different
tasks -- rather, it's contributions being delayed, for IMHO doubtful
gain.

Thanks,
-Karl