Re: Syncing Gnus and Emacs repositories

[Giorgos Keramidas]

On 2007-06-18 15:53, "Stephen J. Turnbull" <address@hidden> wrote:
> Also, David Kastrup is quite right about the deficiencies of CVS.
> XEmacs did something similar to what is being proposed here.  Under
> pressure from people who were not primarily interested in the 21.4
> release, we branched in January 2001, pushing blue-sky projects off on
> a branch, and keeping 21.4 on the trunk.  It immediately became clear
> this was unsustainable due to the difficulty of using cvs annotate,
> cvs diff, and cvs update -j with mainline on a CVS branch.  So in
> April 2001, less than three months later, we transplanted the trunk
> (starting from the fork) to a new release-21-4 branch, and the 21.5
> branch back to the trunk, at fairly high cost in current usefulness of
> annotate, diff and update -j.  However, with mainline on the branch,
> that cost was increasing rapidly, while with mainline on the trunk,
> the cost decreased to negligible by the end of summer 2001.  While in
> the end we avoided total disaster, the rationalization effort was
> unaccompanied by any net benefit whatsoever, in fact, there were net
> costs both before and after the rationalization compared to doing it
> right by putting mainline on the trunk as soon was the 21.4 feature
> freeze was implemented.

That's very interesting.  I am not watching the development of XEmacs
very closely, but can you please describe how developing on a 'release
branch' made things difficult for XEmacs?  Please feel free to email me
privately if this would increase the noise in emacs-devel, without a lot
of benefit for Emacs developers.

I'm asking because of my existing experience with how the FreeBSD CVS
tree is used to work on FreeBSD development.

It may not be very useful for Emacs development, but the model used by
the FreeBSD CVS tree is:

       [1]
    ----X--------------------------> trunk
        |        :        :
        |        :        :
        +-----------X--------X--> RELENG_6
                   [2]      [3]
                    |        |
                    |        |
                    |        +--- RELENG_6_1
                    |
                    |
                    +------------ RELENG_6_0

Where 'X' points are tags, and ':' lines denote selective merging of
features from the CVS trunk.

  1 == RELENG_6_BP
  2 == RELENG_6_0_0_RELEASE
  3 == RELENG_6_1_0_RELEASE

When the CVS trunk is considered ready for the 6.X branch, we freeze
trunk, the release engineering team tags the trunk as RELENG_6_BP and
the RELENG_6 branch is branched off RELENG_6_BP.

Some time after the release branch RELENG_6 stabilizes enough for us to
roll out a release, we freeze the RELENG_6 and finally we tag it with
RELENG_6_0_0_RELEASE and then we create a 'security branch' off the
release tag (RELENG_6_0).

Each release is tagged with RELENG_X_Y_Z_RELEASE.

Each release has an associated RELENG_X_Y security branch, which can
accept _only_ security fixes and nothing else.

Each major line of development has its own RELENG_X 'mainline'.

Development of cutting edge features, which may be unstable for long
periods of time, experimental, or even be completely removed before they
ever hit a release branch is done in the CVS trunk.

Development of 'stable' versions, which can only make conservative
bugfix and security fix changes, is done in the RELENG_X mainline.

I don't know if such a model would fit the development of Emacs, or if
the description was clear enough.  Please feel free to ask any questions
regarding the way we branch or tag FreeBSD, or how the release process
of FreeBSD is organized around CVS.  It if helps us make the development
of Emacs more 'streamlined', then I'll be glad to work with the main
Emacs developers to see which parts of the FreeBSD model can fit the way
the development of Emacs works already and which parts we can adopt to
improve things :)

- Giorgos