Branch for 23.1?

Branch for 23.1?

[David Engster]

The Emacs CVS is now branched for the 23.1 release, so the trunk should
be open again for development soon.

I don't know the usual procedure for Gnus CVS; I guess there should also
be a branch emacs_23_1, so the trunk can be opened again for new feature
commits?

-David

Gnus branches and sync with Emacs (was: Branch for 23.1?)

[Reiner Steib]

On Mon, Jun 22 2009, David Engster wrote:

> The Emacs CVS is now branched for the 23.1 release, so the trunk should
> be open again for development soon.

The Emacs trunk is only open for "non-regression bugfixes":

,----[ http://thread.gmane.org/gmane.emacs.devel/111595/focus=111609 ]
| The trunk is now open for all non-regression bugfixes.  New features can
| also be added to the trunk, but please discuss on emacs-devel first.
`----

,----[ http://thread.gmane.org/gmane.emacs.devel/111595 ]
| As currently planned, we'll use the trunk for developing 23.2.
`----

Is this still the policy for Emacs?

> I don't know the usual procedure for Gnus CVS; I guess there should also
> be a branch emacs_23_1, so the trunk can be opened again for new feature
> commits?

If Gnus developers want to start adding new features to Gnus CVS now,
we also need to have a bug-fix-only Gnus branch as well, say "v5-12",
which is synced with Emacs trunk (to be Emacs 23.2).  v5-12 would also
be used for future Gnus 5.12.* releases.

As there's no Emacs branch (or trunk) for new features, this would
imply that we cannot sync Gnus to Emacs for quite some time (dunno how
are the plans for the next major version of Emacs).

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Gnus branches and sync with Emacs

[Ted Zlatanov]

On Sat, 18 Jul 2009 22:21:23 +0200 Reiner Steib <reinersteib+gmane@imap.cc> wrote: 

RS> If Gnus developers want to start adding new features to Gnus CVS now,
RS> we also need to have a bug-fix-only Gnus branch as well, say "v5-12",
RS> which is synced with Emacs trunk (to be Emacs 23.2).  v5-12 would also
RS> be used for future Gnus 5.12.* releases.

RS> As there's no Emacs branch (or trunk) for new features, this would
RS> imply that we cannot sync Gnus to Emacs for quite some time (dunno how
RS> are the plans for the next major version of Emacs).

First of all, sorry for my commit.  I had assumed that since Emacs got
branched and the trunk was open, it was OK to commit into the Gnus trunk
as well.  I did not check with you and I should have.

Please let me know when I can resume comitting to the Gnus CVS trunk.

Ted

Re: Gnus branches and sync with Emacs

[Chong Yidong]

Ted Zlatanov <tzz@lifelogs.com> writes:

> RS> If Gnus developers want to start adding new features to Gnus CVS now,
> RS> we also need to have a bug-fix-only Gnus branch as well, say "v5-12",
> RS> which is synced with Emacs trunk (to be Emacs 23.2).  v5-12 would also
> RS> be used for future Gnus 5.12.* releases.
>
> RS> As there's no Emacs branch (or trunk) for new features, this would
> RS> imply that we cannot sync Gnus to Emacs for quite some time (dunno how
> RS> are the plans for the next major version of Emacs).
>
> First of all, sorry for my commit.  I had assumed that since Emacs got
> branched and the trunk was open, it was OK to commit into the Gnus trunk
> as well.  I did not check with you and I should have.
>
> Please let me know when I can resume comitting to the Gnus CVS trunk.

Whether the Gnus trunk should be synched to the Emacs trunk depends on
how "unstable" the Gnus maintainers intend to get.

My goal---and I think Stefan envisions something similar---is to have a
relatively short development cycle of a few months, during which we'll
insert a small number of new features (primarily CEDET) alongside the
usual bugfixes, followed by a pretest leading to 23.2.  If the Gnus
maintainers can follow a similar schedule, it might be practical to just
keep the two trunks in synch.

(The recent change of `mail-user-agent' may or may not be consistent
with this plan.  What's not clear right now is the amount of changes
that need to be applied to sort out the incompatibilies between
mail-mode and message-mode.  If the required changes end up being too
destabilizing, we should either switch mail-user-agent back, or fall
back on the alternative plan of using the 23.1 branch for 23.2.)

Re: Gnus branches and sync with Emacs

[Reiner Steib]

On Mon, Jul 20 2009, Chong Yidong wrote:

>> RS> If Gnus developers want to start adding new features to Gnus CVS now,
>> RS> we also need to have a bug-fix-only Gnus branch as well, say "v5-12",
>> RS> which is synced with Emacs trunk (to be Emacs 23.2).  v5-12 would also
>> RS> be used for future Gnus 5.12.* releases.
>>
>> RS> As there's no Emacs branch (or trunk) for new features, this would
>> RS> imply that we cannot sync Gnus to Emacs for quite some time (dunno how
>> RS> are the plans for the next major version of Emacs).
[...]
> Whether the Gnus trunk should be synched to the Emacs trunk depends on
> how "unstable" the Gnus maintainers intend to get.
>
> My goal---and I think Stefan envisions something similar---is to have a
> relatively short development cycle of a few months, during which we'll
> insert a small number of new features (primarily CEDET) alongside the
> usual bugfixes, followed by a pretest leading to 23.2.  If the Gnus
> maintainers can follow a similar schedule, it might be practical to just
> keep the two trunks in synch.

Personally, I could live with such an arrangement, since i didn't have
much time for Gnus development recently.  But I also don't see much
problem to have two branches (like we did with v5-10 for quite a long
time) if other Gnus developers wish to commit new (potentially
destabilizing) features sooner - I seem to recall that we deferred
some contributions during the last months.  Opinions?

> (The recent change of `mail-user-agent' may or may not be consistent
> with this plan.  What's not clear right now is the amount of changes
> that need to be applied to sort out the incompatibilies between
> mail-mode and message-mode.  If the required changes end up being too
> destabilizing, we should either switch mail-user-agent back, or fall
> back on the alternative plan of using the 23.1 branch for 23.2.)

I don't think the change of `mail-user-agent' an Richard's intends WRT
mail-mode/rf2047/mm-* are consistent with this plan, so I'm quite
puzzled about the plans for the Emacs trunk.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Gnus branches and sync with Emacs

[Stefan Monnier]

>> (The recent change of `mail-user-agent' may or may not be consistent
>> with this plan.  What's not clear right now is the amount of changes
>> that need to be applied to sort out the incompatibilies between
>> mail-mode and message-mode.  If the required changes end up being too
>> destabilizing, we should either switch mail-user-agent back, or fall
>> back on the alternative plan of using the 23.1 branch for 23.2.)

> I don't think the change of `mail-user-agent' an Richard's intends WRT
> mail-mode/rf2047/mm-* are consistent with this plan, so I'm quite
> puzzled about the plans for the Emacs trunk.

AFAIK the change of mail-user-agent is not a problem in this regard (we
don't actually need to make message-mode compatible with mail-mode; we
just need to avertise the change more prominently).  But between
gdb-mi.el and the rfc2047 plans, I agree that it looks like trunk is not
headed for a very-short cycle.  So we may very well release a 23.2 from
the release branch rather than from the trunk.  I'm not too worried
about it, tho.


        Stefan

Re: Gnus branches and sync with Emacs

[Ted Zlatanov]

On Mon, 20 Jul 2009 22:42:24 +0200 Reiner Steib <reinersteib+gmane@imap.cc> wrote: 

RS> Personally, I could live with such an arrangement, since i didn't have
RS> much time for Gnus development recently.  But I also don't see much
RS> problem to have two branches (like we did with v5-10 for quite a long
RS> time) if other Gnus developers wish to commit new (potentially
RS> destabilizing) features sooner - I seem to recall that we deferred
RS> some contributions during the last months.  Opinions?

I hope the bzr repository, when available, will make all this easier.

My preference is to have a place, either Gnus trunk or a branch, where I
can commit new code without waiting for approval.  I would prefer that
to be the Gnus trunk, and I think it makes sense to have a Gnus CVS
branch for the purpose of synchronization with Emacs CVS.  IOW, the
synchronization that happens from the Gnus trunk right now should happen
from a "for Emacs" branch, so Gnus developers are not affecting Emacs
developers and vice versa.  Then the burden falls on Reiner or others to
backport things into the "for Emacs" branch when appropriate.

This would bring the Gnus CVS trunk back to the "bleeding edge" status
it had in the past.

Ted

Re: Gnus branches and sync with Emacs

[Reiner Steib]

On Tue, Jul 21 2009, Ted Zlatanov wrote:

> My preference is to have a place, either Gnus trunk or a branch, where I
> can commit new code without waiting for approval.  

Noted.

> I would prefer that to be the Gnus trunk, and I think it makes sense
> to have a Gnus CVS branch for the purpose of synchronization with
> Emacs CVS.  IOW, the synchronization that happens from the Gnus
> trunk right now should happen from a "for Emacs" branch,

This would be the v5-12 branch in my suggestion.

> so Gnus developers are not affecting Emacs developers and vice
> versa.  

Just to clarify: The question is not _whether or not_ to sync, but
_when and how_ we sync the Gnus repository to Emacs' repository.

> Then the burden falls on Reiner or others to backport things into
> the "for Emacs" branch when appropriate.

The "burden" basically is on Miles, but it's more or less
automatically.  Well, at least if every developer commits bugfixes to
the bugfix-branch (which will be synced to the development branch) by
Miles.

> This would bring the Gnus CVS trunk back to the "bleeding edge" status
> it had in the past.

The Gnus trunk also had long stabilizing periods (e.g. from 5.10.1 to
5.10.6).

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Gnus branches and sync with Emacs

[Ted Zlatanov]

On Tue, 21 Jul 2009 19:27:00 +0200 Reiner Steib <reinersteib+gmane@imap.cc> wrote: 

>> Then the burden falls on Reiner or others to backport things into
>> the "for Emacs" branch when appropriate.

RS> The "burden" basically is on Miles, but it's more or less
RS> automatically.  Well, at least if every developer commits bugfixes to
RS> the bugfix-branch (which will be synced to the development branch) by
RS> Miles.

Actually the burden is now on the Gnus developers to backport their
changes to the bugfix Gnus branch in your scenario.  The actual followup
sync is up to Miles.  With CVS this is a bit of a pain (compared to SVN,
Git, etc.) so I hope we can move Gnus development off CVS soon.  Not
that I am complaining about backporting, it's not a lot of work, it's
just tedious.

>> This would bring the Gnus CVS trunk back to the "bleeding edge" status
>> it had in the past.

RS> The Gnus trunk also had long stabilizing periods (e.g. from 5.10.1 to
RS> 5.10.6).

Sure.  The online info, however, says:

http://www.gnus.org/distribution.html

"Please note that what you're getting is probably not even a
bleeding-edge Gnus, but a severly hemorrhaging one."

so I think stability is supposed to be an exception, at least when that
was written.  We should probably revise gnus.org anyhow, lots of the
information is outdated.

Ted

Re: Gnus branches and sync with Emacs

[Christoph Conrad]

Hi Ted,

> so I think stability is supposed to be an exception, at least when
> that was written.

When trunk CVS gnus is meant here: i am using it for several years now,
and for a very long time it has been stable.

Regards,
Christoph

Re: Gnus branches and sync with Emacs

[Ted Zlatanov]

On Tue, 21 Jul 2009 22:43:35 +0200 Christoph Conrad <christoph.conrad@gmx.de> wrote: 

CC> Hi Ted,
>> so I think stability is supposed to be an exception, at least when
>> that was written.

CC> When trunk CVS gnus is meant here: i am using it for several years now,
CC> and for a very long time it has been stable.

I meant stability in the sense of fewer updates to stabilize the source
code (which reminds me of the quip that biology has a word for "stable"
and it's "dead").  Perhaps the right word was "quiescense" :)

I agree the Gnus trunk has been very reliable since I can remember, but
my point is that if I want to put in a bleeding-edge feature I shouldn't
have to wait for the next release.

There's definitely an implicit agreement that no such features should be
pushed if they break current setups or endanger user data, especially if
they are on by default.  I am not implying otherwise.

Ted

Re: Gnus branches and sync with Emacs

[Stephen J. Turnbull]

Ted Zlatanov writes:
 > On Mon, 20 Jul 2009 22:42:24 +0200 Reiner Steib <reinersteib+gmane@imap.cc> wrote: 
 > 
 > RS> Personally, I could live with such an arrangement, since i didn't have
 > RS> much time for Gnus development recently.  But I also don't see much
 > RS> problem to have two branches

 > I hope the bzr repository, when available, will make all this easier.

Maybe a little.  In a technical sense it will be substantially less
work (but probably not nearly as low as half as much work) for whoever
does the syncing.  However, if you're not going to do the work, you
still have to find somebody else to do it.  You also have to change
the habits of those who are currently active.

What the bzr repo will make definitely *much* easier *immediately* is
for you to keep your own bleeding edge branch locally, and then push
from there to the Gnus mainline when it's "open for commits".  You'll
need to learn more of bzr than you might otherwise, but it's worth it.

Re: Gnus branches and sync with Emacs

[Steinar Bang]

>>>>> "Stephen J. Turnbull" <stephen@xemacs.org>:

> What the bzr repo will make definitely *much* easier *immediately* is
> for you to keep your own bleeding edge branch locally, and then push
> from there to the Gnus mainline when it's "open for commits".  You'll
> need to learn more of bzr than you might otherwise, but it's worth it.

FWIW I have been using the Gnus trunk for over ten years now (closing on
twelve, I think), and except for when lars were rolling releases, there
has never been a time with bleeding edge work hasn't been ok to do on
the trunk.

If you are going to do big changes, it's much better to let them loose
on a bunch of testers as early as possible, instead of sitting with them
on a branch just testing them yourself, and then committing them
big-bang to the trunk.

Re: Gnus branches and sync with Emacs

[Stephen J. Turnbull]

Steinar Bang writes:
 > >>>>> "Stephen J. Turnbull" <stephen@xemacs.org>:
 > 
 > > What the bzr repo will make definitely *much* easier *immediately* is
 > > for you to keep your own bleeding edge branch locally, and then push
 > > from there to the Gnus mainline when it's "open for commits".  You'll
 > > need to learn more of bzr than you might otherwise, but it's worth it.
 > 
 > FWIW I have been using the Gnus trunk for over ten years now (closing on
 > twelve, I think), and except for when lars were rolling releases,

I'm not suggesting *any* workflow for Gnus.  I'm saying that
some things become easier with a dVCS and others do not.

 > If you are going to do big changes, it's much better to let them loose
 > on a bunch of testers as early as possible, instead of sitting with them
 > on a branch just testing them yourself, and then committing them
 > big-bang to the trunk.

Sure; but "early as possible" definitely varies by project.  Gnus as
an independent project from which Emacs syncs occasionally is a rather
different entity from one which is more closely integrated to Emacs,
eg, supplying reusable components to mail-mode and eventually RMail.