Release procedure.

Release procedure.

[Karl Fogel]

I've long been baffled that trunk work is affected by the fact that a
release is under way.  We ought to be able to do both, or else there's
some technical failure in how we're using our version control system.

I see that others are also frustrated and less productive because of
this, as the recent comments in this thread indicate:

   http://lists.gnu.org/archive/html/emacs-devel/2007-05/threads.html#00012

Of course, it's possible that I simply don't understand Emacs's
release procedures.  Are they written up anywhere?  I couldn't find
them in my working copy.

Could someone (RMS? anyone?) say exactly what our release procedure
is, and why it is that way?  Then we could evaluate whether it's the
best procedure for our goals.  Or we might discover we disagree on the
goals -- but that would be useful to find out, too.

For the record, my idea of a good release procedure is here:

   http://producingoss.com/html-chunk/release-branches.html

-Karl

Re: Release procedure.

[Stefan Monnier]

> 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.


        Stefan

Re: Release procedure.

[Karl Fogel]

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

Re: Release procedure.

[David Kastrup]

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.

Well, but we _did_ branch, and there is a complete lack of directions
about what the branch is supposed to be for.  Previously it was agreed
that we'd use the trunk after branching for merging in multi-tty and
emacs-unicode-2, and use the branch for the 22.x series.

At the current point of time, however, it appears like both trunk and
release branch are not supposed to be worked upon except by special
notice, and then both are synchronously updated.

It does not make sense, and it makes it impossible for anybody to do
serious work.

-- 
David Kastrup

Re: Release procedure.

[Karl Fogel]

David Kastrup <dak@gnu.org> writes:
> Well, but we _did_ branch, and there is a complete lack of directions
> about what the branch is supposed to be for.  Previously it was agreed
> that we'd use the trunk after branching for merging in multi-tty and
> emacs-unicode-2, and use the branch for the 22.x series.
>
> At the current point of time, however, it appears like both trunk and
> release branch are not supposed to be worked upon except by special
> notice, and then both are synchronously updated.
>
> It does not make sense, and it makes it impossible for anybody to do
> serious work.

I can't confidently assert that there's a complete lack of direction
about what the branch is for, because it's always possible that there
was such direction and I simply didn't see it (although a permanent
file in the tree would be better than a mailing list post, for that).

But, just as a data point: I'm in the same boat with David.  For
whatever reason, I also do not understand what the branch is for.

Re: Release procedure.

[Chong Yidong]

Karl Fogel <kfogel@red-bean.com> writes:

> But, just as a data point: I'm in the same boat with David.  For
> whatever reason, I also do not understand what the branch is for.

Originally, the idea was to release Emacs 22.1 promptly after
branching.  The branch would then be used for 22.x development.  The
trouble now is that the release is stuck, mainly (but not exclusively)
because of the python issue.

Re: Release procedure.

[Stefan Monnier]

>> But, just as a data point: I'm in the same boat with David.  For
>> whatever reason, I also do not understand what the branch is for.

> Originally, the idea was to release Emacs 22.1 promptly after
> branching.  The branch would then be used for 22.x development.  The
> trouble now is that the release is stuck, mainly (but not exclusively)
> because of the python issue.

Being stuck is not inherently a problem: the promptness of "promptly after
branching" does not have to be measured in seconds but can just as well be
measured in revisions or lines changed.


        Stefan