New branch

New branch

[Stefan Monnier]

I have just opened a new branch sftp://bzr.sv.gnu.org/srv/bzr/emacs/pending
which is intended to receive patches that cannot be installed in trunk
because they're not bug-fixes.

I.e. the branch is there so instead of saying "please come back later"
we can just install the corresponding patch/package into this branch.


        Stefan

Re: New branch

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 27 Jan 2010 21:37:34 -0500
> 
> I have just opened a new branch sftp://bzr.sv.gnu.org/srv/bzr/emacs/pending
> which is intended to receive patches that cannot be installed in trunk
> because they're not bug-fixes.

Does this mean that there will be no release branch for Emacs 23.2,
and it will be released from the trunk instead?

Re: New branch

[Stefan Monnier]

>> I have just opened a new branch sftp://bzr.sv.gnu.org/srv/bzr/emacs/pending
>> which is intended to receive patches that cannot be installed in trunk
>> because they're not bug-fixes.
> Does this mean that there will be no release branch for Emacs 23.2,
> and it will be released from the trunk instead?

That could be, tho I haven't thought much about it yet.
But note that in the context of Bzr, those questions don't have the same
importance&meaning as within CVS.  After all, creating a branch is
nothing else than cloning, so initially the new branch is absolutely
identical to the "parent".
I expect at some point we'll do something like:

  (cd pending; bzr merge ../trunk; bzr commit)
  mv trunk emacs-23.2
  mv pending trunk

or maybe

  bzr clone trunk emacs-23.2
  (cd trunk; bzr merge ../pending; bzr commit)
  rm -rf pending


-- Stefan

Re: New branch

[Óscar Fuentes]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> That could be, tho I haven't thought much about it yet.
> But note that in the context of Bzr, those questions don't have the same
> importance&meaning as within CVS.  After all, creating a branch is
> nothing else than cloning, so initially the new branch is absolutely
> identical to the "parent".

This is correct. But you have to think too about the branches out there
that are pointing to upstream branches...

> I expect at some point we'll do something like:
>
>   (cd pending; bzr merge ../trunk; bzr commit)
>   mv trunk emacs-23.2
>   mv pending trunk
>
> or maybe
>
>   bzr clone trunk emacs-23.2
>   (cd trunk; bzr merge ../pending; bzr commit)
>   rm -rf pending

... for the people that at that time have branches of `trunk' and
`pending', if they do not adjust their reference branches to match the
change, they can get confused: the lesser problem is the disappearance
of `pending', which it is just an annoyance, but `trunk' suddendly
taking the role of the former `pending' branch can be a bit disturbing,
as you are switching roles, and if someone does not notice it, he can
commit to the "new" `trunk' something intended for the "old" trunk.

I don't know if Emacs hackers are up to date enough with notices on the
ml to be aware of the transition.

In any case, people would have to do a bit of housekeeping when you
rename a branch.

In the future, I suggest creating branches with a name that conveys its
purpose (trunk can be the perennial development branch, then we would
have `emacs-XX.X', etc) and keep those names forever. This requires
almost no housekeeping on the developers part, except for cloning
emacs-XX.X when it is created, which is much simpler than adjusting
branch references.

Re: New branch

[Chong Yidong]

Óscar Fuentes <ofv@wanadoo.es> writes:

> This is correct. But you have to think too about the branches out there
> that are pointing to upstream branches...

Yes, and the idea is to use trunk as a signal for development
priorities.  Right now, we want the focus to be on fixing bugs, so the
Emacs 23.2 code is on trunk.  The `pending' branch is for those few who
are looking ahead to Emacs 24, but we don't want that to encourage that
for the bulk of developers, yet.

Re: New branch

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Thu, 28 Jan 2010 15:12:30 -0500
> Cc: emacs-devel@gnu.org
> 
> Óscar Fuentes <ofv@wanadoo.es> writes:
> 
> > This is correct. But you have to think too about the branches out there
> > that are pointing to upstream branches...
> 
> Yes, and the idea is to use trunk as a signal for development
> priorities.  Right now, we want the focus to be on fixing bugs, so the
> Emacs 23.2 code is on trunk.  The `pending' branch is for those few who
> are looking ahead to Emacs 24, but we don't want that to encourage that
> for the bulk of developers, yet.

But the disadvantages pointed out by Óscar of changing the semantics
of trunk, pending, and other non-specific names, are real.  So I'd
really prefer that we use a special branch for releasing 23.2, leaving
the trunk for future versions, because then the semantics of trunk
would not change under our feet one day.

Re: New branch

[Stefan Monnier]

> ... for the people that at that time have branches of `trunk' and
> `pending', if they do not adjust their reference branches to match the
> change, they can get confused: the lesser problem is the disappearance
> of `pending', which it is just an annoyance, but `trunk' suddendly
> taking the role of the former `pending' branch can be a bit disturbing,
> as you are switching roles, and if someone does not notice it, he can
> commit to the "new" `trunk' something intended for the "old" trunk.

trunk wouldn't take the role of the pending branch: it would take the
content of the pending branch but keep its role of "where development is
focused", so I don't think there's any problem.  It matches previous CVS
pratice in this regard.

> In the future, I suggest creating branches with a name that conveys its
> purpose (trunk can be the perennial development branch, then we would
> have `emacs-XX.X', etc) and keep those names forever. This requires
> almost no housekeeping on the developers part, except for cloning
> emacs-XX.X when it is created, which is much simpler than adjusting
> branch references.

When I tried to do that, I bumped into the problem that I can't have
a symlink "trunk" pointing to the "emacs-23" branch (because
bzr.sv.gnu.org's http server doesn't honor symlinks).


        Stefan

Re: New branch

[Óscar Fuentes]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> trunk wouldn't take the role of the pending branch: it would take the
> content of the pending branch but keep its role of "where development is
> focused", so I don't think there's any problem.  It matches previous CVS
> pratice in this regard.

Well, one thing is wathever meaning you want to associate with each
branch name, and another thing is the contents of the branch.

Apart from creating confussion when the rename takes place, there are
potential problems:

First: mirrors will suddenly appear as diverged branches. Hopefully
people will know about the change in advance or come here to ask before
trying to "fix" the problem and possibly screw their setups of send
upstream a bag of garbage made of revisions from the previous branch and
merges of the new one. Automatic mirrors like the one in Launchpad will
be broken. Likewise for the setups of users who track Emacs
development. I foresee all sorts of grief and despair :-)

Second: I don't know the effects of switching the master branch in
midair for a bound branch. It would be a good thing to ask about this in
the bzr ml for knowing about potential problems.

>> In the future, I suggest creating branches with a name that conveys its
>> purpose (trunk can be the perennial development branch, then we would
>> have `emacs-XX.X', etc) and keep those names forever. This requires
>> almost no housekeeping on the developers part, except for cloning
>> emacs-XX.X when it is created, which is much simpler than adjusting
>> branch references.
>
> When I tried to do that, I bumped into the problem that I can't have
> a symlink "trunk" pointing to the "emacs-23" branch (because
> bzr.sv.gnu.org's http server doesn't honor symlinks).

I don't see how symlinks could help here.

Re: New branch

[Stefan Monnier]

> First: mirrors will suddenly appear as diverged branches. Hopefully

No, check again: the branches move strictly forward, mirrors should be
just fine.  The only potential issue is whether the "mainline history"
is preserved (see recent discussion about that).

>> When I tried to do that, I bumped into the problem that I can't have
>> a symlink "trunk" pointing to the "emacs-23" branch (because
>> bzr.sv.gnu.org's http server doesn't honor symlinks).
> I don't see how symlinks could help here.

I want/need a stable name to refer to "the branch where development
takes place".  So if that branch can be emacs-23 for a while and
emacs-24 later, I need something like symlinks in order to be able to
have trunk point to emacs-23 first and emacs-24 later.


        Stefan

Re: New branch

[Stephen J. Turnbull]

Stefan Monnier writes:

 > But note that in the context of Bzr, those questions don't have the same
 > importance&meaning as within CVS.

That's right; they're *far* more important! ;-)

 > After all, creating a branch is
 > nothing else than cloning, so initially the new branch is absolutely
 > identical to the "parent".
 > I expect at some point we'll do something like:
 > 
 >   (cd pending; bzr merge ../trunk; bzr commit)
 >   mv trunk emacs-23.2
 >   mv pending trunk

Gawd, no!  For that to work, you really want to be rebasing pending on
to trunk after *every* commit to trunk.  Otherwise, what you propose
here will AFAICT result in exactly the kind of Mainline Twist that you
personally just set ARO to prevent.  But that seems like makework to
me.  The whole point of having a pending branch should be that they
can go their separate ways for a while, and during that while, commits
of new code to the public branches are discouraged and require effort
to (a) do and (b) test.

If you are not trying to discourage work on new code, then you should
cut a separate release branch.

 > or maybe
 > 
 >   bzr clone trunk emacs-23.2
 >   (cd trunk; bzr merge ../pending; bzr commit)
 >   rm -rf pending

Better, but that last line should give you pause.  Sure, it's needed,
because pending is now obsolete.  But bzr gives no way to notify
people of that except that their attempts to pull or push will fail (I
hope).

It seems to me that pending is not a great idea.  Patches that don't
belong in trunk can just stay in personal private or public branches
until trunk opens again.  If pending would really accumulate
significant amounts of work, your release process has more problems
than just "where to put pending work".

Re: New branch

[Stefan Monnier]

> until trunk opens again.  If pending would really accumulate
> significant amounts of work, your release process has more problems
> than just "where to put pending work".

What else is new?


        Stefan

Re: New branch

[Kenichi Handa]

In article <jwvtyu7gdva.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I have just opened a new branch sftp://bzr.sv.gnu.org/srv/bzr/emacs/pending
> which is intended to receive patches that cannot be installed in trunk
> because they're not bug-fixes.

> I.e. the branch is there so instead of saying "please come back later"
> we can just install the corresponding patch/package into this branch.

Please teach me the bzr command sequence to do that.  Should
I repeast this same procedure used for checking out trunk
branch?

% cd emacs
% bzr branch sftp://USERNAME@bzr.savannah.gnu.org/srv/bzr/emacs/trunk trunk
% cd trunk
% echo "public_branch = sftp://USERNAME@bzr.savannah.gnu.org/srv/bzr/emacs/trunk" >> .bzr/branch/branch.conf
% bzr bind sftp://USERNAME@bzr.savannah.gnu.org/srv/bzr/emacs/trunk
% cd ..

Or, can I use some shortcut to utilize the
already-checked-out trunk branch?

---
Kenichi Handa
handa@m17n.org

Re: New branch

[Stefan Monnier]

> Please teach me the bzr command sequence to do that.  Should
> I repeast this same procedure used for checking out trunk
> branch?

> % cd emacs
> % bzr branch sftp://USERNAME@bzr.savannah.gnu.org/srv/bzr/emacs/trunk trunk
> % cd trunk
> % echo "public_branch = sftp://USERNAME@bzr.savannah.gnu.org/srv/bzr/emacs/trunk" >> .bzr/branch/branch.conf
> % bzr bind sftp://USERNAME@bzr.savannah.gnu.org/srv/bzr/emacs/trunk
> % cd ..

> Or, can I use some shortcut to utilize the
> already-checked-out trunk branch?

I'd go to your local shared repository (presumably the .../emacs where
you have a `trunk' subdirectory) and then just do

   bzr co sftp://bzr.savannah.gnu.org/srv/bzr/emacs/pending


-- Stefan

Re: New branch

[Kenichi Handa]

In article <jwvk4uvuk3i.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I'd go to your local shared repository (presumably the .../emacs where
> you have a `trunk' subdirectory) and then just do

>    bzr co sftp://bzr.savannah.gnu.org/srv/bzr/emacs/pending

Thank you.  I've just done it.  Now I have .../emacs/pending
directory.  Then, I can directly work in that directory for
quick fixes, and it is better to create another task branch
for more complex work, right?

---
Kenichi Handa
handa@m17n.org

Re: New branch

[Stefan Monnier]

>> I'd go to your local shared repository (presumably the .../emacs where
>> you have a `trunk' subdirectory) and then just do
>> bzr co sftp://bzr.savannah.gnu.org/srv/bzr/emacs/pending
> Thank you.  I've just done it.  Now I have .../emacs/pending
> directory.  Then, I can directly work in that directory for
> quick fixes, and it is better to create another task branch
> for more complex work, right?

Exactly,


        Stefan