Re: Oort Gnus branch

Re: Oort Gnus branch

[Sean Doran]

| Another thought is that maybe we would like to do it like Emacs does
| it.  So, how does Emacs handle the branches?

NetBSD creates a tag to represent a forthcoming release; ongoing day-to-day
"-current" development continues in the trunk, while changes to
the potential-release-tag may be pulled-up only by a "release engineer".
Generally only important bug fixes, rather than new features, are pulled up.

At some point the releng folks are satisfied that the branch is ready
to be tarred up as an actual release, and out goes the latest non-CVS version.

Likewise, critical fixes can be pulled up into older already-released
branches, for the benefit of people who deliberately run older releases
for stability or other reasons.  

	Sean.

Re: Oort Gnus branch

[Kai Großjohann]

On Sun, 1 Oct 2000, Sean Doran wrote:

> NetBSD creates a tag to represent a forthcoming release;

Ah, yes.  I know that approach from FreeBSD.  I like it.  But like I
said, adjusting to the way Emacs does it is a worthwhile thought.

kai
-- 
I like BOTH kinds of music.

Re: Oort Gnus branch

[Russ Allbery]

Sean Doran <smd@ebone.net> writes:

> NetBSD creates a tag to represent a forthcoming release; ongoing
> day-to-day "-current" development continues in the trunk, while changes
> to the potential-release-tag may be pulled-up only by a "release
> engineer".  Generally only important bug fixes, rather than new
> features, are pulled up.

> At some point the releng folks are satisfied that the branch is ready to
> be tarred up as an actual release, and out goes the latest non-CVS
> version.

For INN, we copied this model and it's worked quite well.  I prefer having
the release on a branch; the difficulty in committing things to the branch
helps make sure that only important fixes go in there.  :)

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Oort Gnus branch

[ShengHuo ZHU]

October is coming. Gnus v5.9.0 emerges. It's time for oGnus.  If no
one objects, I'll create the branch.

ShengHuo

Re: Oort Gnus branch

[Norbert Koch]

ShengHuo ZHU <zsh@cs.rochester.edu> wrote:

Hi!

> October is coming. Gnus v5.9.0 emerges. It's time for oGnus.  If no
> one objects, I'll create the branch.

Will this be the main development branch or do we have to check in/out
to/from a new release tag?

Re: Oort Gnus branch

[ShengHuo ZHU]

Norbert Koch <nk@LF.net> writes:

> ShengHuo ZHU <zsh@cs.rochester.edu> wrote:
> 
> Hi!
> 
> > October is coming. Gnus v5.9.0 emerges. It's time for oGnus.  If no
> > one objects, I'll create the branch.
> 
> Will this be the main development branch or do we have to check in/out
> to/from a new release tag?

I think it will be a new branch.

ShengHuo

Re: Oort Gnus branch

[Kai Großjohann]

On Sun, 1 Oct 2000, ShengHuo ZHU wrote:

> I think it will be a new branch.

IMHO, it would be better if the main trunk was always the most current
development version.  This way, people who use CVS get to test the
most current version -- that's what CVS is here for, right?  Also, I
think we expect the 5.8/5.9 lines of development to be rather short,
no?

I think this is the first time that a major release is begun while
using CVS, isn't it?  If it wasn't the first time, we could have
looked at how it was done previously.

Another thought is that maybe we would like to do it like Emacs does
it.  So, how does Emacs handle the branches?

kai
-- 
I like BOTH kinds of music.

Re: Oort Gnus branch

[Daniel Pittman]

On 01 Oct 2000, Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE>
wrote:

> On Sun, 1 Oct 2000, ShengHuo ZHU wrote:
> 
>> I think it will be a new branch.
> 
> IMHO, it would be better if the main trunk was always the most current
> development version.  This way, people who use CVS get to test the
> most current version -- that's what CVS is here for, right?  Also, I
> think we expect the 5.8/5.9 lines of development to be rather short,
> no?

I would have to second this. Personal experience with CVS suggests that
you do a far, far better thing putting the newest development on head.

[...]

> Another thought is that maybe we would like to do it like Emacs does
> it.  So, how does Emacs handle the branches?

I don't know about Emacs, but XEmacs was doing trunk development on a
branch, but plan on moving it to the head branch.

        Daniel

-- 
We close our eyes and look in opposite direction.
We ignore the threats and hope they'll go away.
We refuse to pay attention to the dangers we create
in the name of our fathers we kill our children.
        -- Covenant, _Theremin_

Re: Oort Gnus branch

[Norbert Koch]

Daniel Pittman <daniel@rimspace.net> wrote:

Hi!

> I would have to second this. Personal experience with CVS suggests that
> you do a far, far better thing putting the newest development on head.

I absolutely agree to this.
 
> I don't know about Emacs, but XEmacs was doing trunk development on a
> branch, but plan on moving it to the head branch.

As usual it lacks time ;-/

norbert.

Re: Oort Gnus branch

[ShengHuo ZHU]

Daniel Pittman <daniel@rimspace.net> writes:

> > Another thought is that maybe we would like to do it like Emacs does
> > it.  So, how does Emacs handle the branches?
> 
> I don't know about Emacs, but XEmacs was doing trunk development on a
> branch, but plan on moving it to the head branch.

AFAIK, Emacs has no branch at all.

ShengHuo

Re: Oort Gnus branch

[William M. Perry]

ShengHuo ZHU <zsh@cs.rochester.edu> writes:

> Daniel Pittman <daniel@rimspace.net> writes:
> 
> > > Another thought is that maybe we would like to do it like Emacs does
> > > it.  So, how does Emacs handle the branches?
> > 
> > I don't know about Emacs, but XEmacs was doing trunk development on a
> > branch, but plan on moving it to the head branch.
> 
> AFAIK, Emacs has no branch at all.

It will once I start working on the GTK variant.

-bp

Re: Oort Gnus branch

[Dave Love]

>>>>> "WMP" == William M Perry <wmperry@aventail.com> writes:

 >> AFAIK, Emacs has no branch at all.

 WMP> It will once I start working on the GTK variant.

For what it's worth, there are already some branches in the tree and
there will eventually be release branches and/or pending branches.  We
didn't start with CVS early enough to have 20.x branches.

Re: Oort Gnus branch

[Bruce Stephens]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

[...]

> IMHO, it would be better if the main trunk was always the most current
> development version.  This way, people who use CVS get to test the
> most current version -- that's what CVS is here for, right?  Also, I
> think we expect the 5.8/5.9 lines of development to be rather short,
> no?
> 
> I think this is the first time that a major release is begun while
> using CVS, isn't it?  If it wasn't the first time, we could have
> looked at how it was done previously.
> 
> Another thought is that maybe we would like to do it like Emacs does
> it.  So, how does Emacs handle the branches?

Don't know about Emacs, but XEmacs does it the wrong way around: the
new development is on a branch (release-21-2).  (There's a comment on
the web page somewhere that they plan to change this.)

Your initial paragraph describes it as it should be, IMHO: cut a
branch to support bug fixes and things for pgnus, and ognus should be
on the head.

Re: Oort Gnus branch

[Karl Eichwalder]

ShengHuo ZHU <zsh@cs.rochester.edu> writes:

> I think it will be a new branch.

As long as only a few hackers will do checkins this works.  Otherwise
it's more secure to "protect" the stable sources making them a branch.

-- 
work : ke@suse.de                          |          ------    ,__o
     : http://www.suse.de/~ke/             |         ------   _-\_<,
home : keichwa@gmx.net                     |        ------   (*)/'(*)

Re: Oort Gnus branch

[Florian Weimer]

ShengHuo ZHU <zsh@cs.rochester.edu> writes:

> October is coming. Gnus v5.9.0 emerges. It's time for oGnus.  If no
> one objects, I'll create the branch.

Please do not forget to move the contents of lisp/ChangeLog to a file
lisp/ChangeLog.1 when starting Gnus v5.9.0.

Thanks from Florian, who still suffers from small bandwidth. :-/