Next pretest, and regressions policy

Next pretest, and regressions policy

[Chong Yidong]

I plan to make the next pretest on April 1.  After this weekend, please
commit only fixes for regressions against Emacs 23.4, apart from
documentation fixes.  If you would like to commit a fix for a
non-regression bug, please discuss on emacs-devel first.

Thank you.

Re: Next pretest, and regressions policy

[Bastien]

Chong Yidong <cyd@gnu.org> writes:

> I plan to make the next pretest on April 1.  

I released Org 7.8.07, which I will merge into Emacs trunk
tomorrow morning.  7.8.07 is a bugfix release against 7.8.03,
the current Org version in Emacs.

-- 
 Bastien

Re: Next pretest, and regressions policy

[Bastien]

Bastien <bzg@gnu.org> writes:

> Chong Yidong <cyd@gnu.org> writes:
>
>> I plan to make the next pretest on April 1.  
>
> I released Org 7.8.07, which I will merge into Emacs trunk
> tomorrow morning.  

Done.  I carefully reviewed the ChangeLogs, but if anything
looks wrong or suspicious, please let me know.

Thanks,

-- 
 Bastien

Re: Next pretest, and regressions policy

[=?utf-8?Q?=C3=93scar_Fuentes?=]

Bastien <bzg@gnu.org> writes:

>> I released Org 7.8.07, which I will merge into Emacs trunk
>> tomorrow morning.  
>
> Done.  I carefully reviewed the ChangeLogs, but if anything
> looks wrong or suspicious, please let me know.

Hello Bastien.

At a first glance, there are places where copyright notices and other
boilerplate are overwritten with older text. The most glaring case is
this:

=== modified file 'lisp/org/ob-fortran.el'
--- a/lisp/org/ob-fortran.el	2012-01-10 06:20:22 +0000
+++ b/lisp/org/ob-fortran.el	2012-04-01 09:49:25 +0000
@@ -1,32 +1,29 @@
 ;;; ob-fortran.el --- org-babel functions for fortran
 
-;; Copyright (C) 2011-2012  Free Software Foundation, Inc.
+;; Copyright (C) 2011-2012 Sergey Litvinov, Eric Schulte
 
-;; Authors: Sergey Litvinov
-;;	    Eric Schulte
+;; Authors: Sergey Litvinov (based on ob-C.el by Eric Schulte), Eric Schulte
 ;; Keywords: literate programming, reproducible research, fortran
 ;; Homepage: http://orgmode.org
-;; Version: 7.8.02
-
-;; This file is part of GNU Emacs.
-
-;; GNU Emacs is free software: you can redistribute it and/or modify
+
+;; This program is free software; you can redistribute it and/or modify


All other occurrences of "Copyright" on your commit are an indication of
a mistake.

I suggest that, before syncing, you obtain a diff from the bzr (or git)
emacs repo that contains all changes to org since your last sync, commit
the diff onto your org sources and then proceed with the new sync.

Re: Next pretest, and regressions policy

[Stefan Monnier]

> At a first glance, there are places where copyright notices and other
> boilerplate are overwritten with older text. The most glaring case is
> this:

Once again: please *never ever* overwrite files.  Always apply
a patch instead.


        Stefan

Re: Next pretest, and regressions policy

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> At a first glance, there are places where copyright notices and other
>> boilerplate are overwritten with older text. The most glaring case is
>> this:
>
> Once again: please *never ever* overwrite files.  Always apply
> a patch instead.

Please fix this ASAP, Bastien.  I will wait for confirmation from you
that this is fixed before making the pretest.

Re: Next pretest, and regressions policy

[Bastien]

Chong Yidong <cyd@gnu.org> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> At a first glance, there are places where copyright notices and other
>>> boilerplate are overwritten with older text. The most glaring case is
>>> this:
>>
>> Once again: please *never ever* overwrite files.  Always apply
>> a patch instead.
>
> Please fix this ASAP, Bastien.  I will wait for confirmation from you
> that this is fixed before making the pretest.

This is fixed now.

-- 
 Bastien

Re: Next pretest, and regressions policy

[Bastien]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> At a first glance, there are places where copyright notices and other
>> boilerplate are overwritten with older text. The most glaring case is
>> this:
>
> Once again: please *never ever* overwrite files.  Always apply
> a patch instead.

Mhh.. okay.

-- 
 Bastien

Re: Next pretest, and regressions policy

[Bastien]

Hi Oscar,

"=?utf-8?Q?=C3=93scar_Fuentes?=" <ofv@wanadoo.es> writes:

> I suggest that, before syncing, you obtain a diff from the bzr (or git)
> emacs repo that contains all changes to org since your last sync, commit
> the diff onto your org sources and then proceed with the new sync.

Understood.  Thanks for the advice!

-- 
 Bastien

Re: Next pretest, and regressions policy

[Chong Yidong]

Bastien <bzg@gnu.org> writes:

>>> Once again: please *never ever* overwrite files.  Always apply
>>> a patch instead.
>>
>> Please fix this ASAP, Bastien.  I will wait for confirmation from you
>> that this is fixed before making the pretest.
>
> This is fixed now.

Thanks.

patch vs. overwrite in bzr [was: Next pretest, and regressions policy]

[Roland Winkler]

On Sun, Apr 01 2012, Stefan Monnier wrote:
>> At a first glance, there are places where copyright notices and other
>> boilerplate are overwritten with older text. The most glaring case is
>> this:
>
> Once again: please *never ever* overwrite files.  Always apply
> a patch instead.

I read this at several occassions. -- I am not an expert with bzr and I
was wondering whether "never overwriting files" translates into a
recommended work flow with bzr.

Most of my knowledge about using bzr with emacs development stems from
http://www.emacswiki.org/emacs/BzrForEmacsDevs
where I couldn't find anything about this.

Thanks,

Roland

Re: patch vs. overwrite in bzr [was: Next pretest, and regressions policy]

[Óscar Fuentes]

Roland Winkler <winkler@gnu.org> writes:

> On Sun, Apr 01 2012, Stefan Monnier wrote:
>>> At a first glance, there are places where copyright notices and other
>>> boilerplate are overwritten with older text. The most glaring case is
>>> this:
>>
>> Once again: please *never ever* overwrite files.  Always apply
>> a patch instead.
>
> I read this at several occassions. -- I am not an expert with bzr and I
> was wondering whether "never overwriting files" translates into a
> recommended work flow with bzr.

Stefan's advice has nothing to do with bzr. It is about not blindly
overwriting changes made on the emacs repo with the new version of the
externally-maintained package (`Org' is in this case.) Applying a patch
gives a lot more opportunities for noticing conflicts (suppossing that
the hacker cares to examine the output of the patch command, that is.)

[snip]

Re: patch vs. overwrite in bzr [was: Next pretest, and regressions policy]

[Bastien]

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

> Roland Winkler <winkler@gnu.org> writes:
>
>> On Sun, Apr 01 2012, Stefan Monnier wrote:
>>>> At a first glance, there are places where copyright notices and other
>>>> boilerplate are overwritten with older text. The most glaring case is
>>>> this:
>>>
>>> Once again: please *never ever* overwrite files.  Always apply
>>> a patch instead.
>>
>> I read this at several occassions. -- I am not an expert with bzr and I
>> was wondering whether "never overwriting files" translates into a
>> recommended work flow with bzr.
>
> Stefan's advice has nothing to do with bzr. It is about not blindly
> overwriting changes made on the emacs repo with the new version of the
> externally-maintained package (`Org' is in this case.) Applying a patch
> gives a lot more opportunities for noticing conflicts (suppossing that
> the hacker cares to examine the output of the patch command, that is.)

The problem is: how to create a patch from Org git repo that can be
easily applied to Emacs bzr repo.

If someone can come up with a workable solution, that'd help me a lot.

Oscar, you said:

> I suggest that, before syncing, you obtain a diff from the bzr (or git)
> emacs repo that contains all changes to org since your last sync, commit
> the diff onto your org sources and then proceed with the new sync.

Which is theoretically fine... but if someone can actually *test* the
suggested workflow, I'm all ears.

Thanks!

-- 
 Bastien

Re: patch vs. overwrite in bzr

[=?utf-8?Q?=C3=93scar_Fuentes?=]

Bastien <bzg@gnu.org> writes:

> The problem is: how to create a patch from Org git repo that can be
> easily applied to Emacs bzr repo.

I don't know how the file structure of Org maps to Emacs' but this
should work for obtaining the changes made to `lisp' directory of Org:

`git diff COMMIT1 COMMIT2 lisp > changes-in-org-lisp.patch'

where COMMIT1 is the range of revisions containing the changes you want
to incorporate into Emacs. Then, on the Emacs source tree, cd to
lisp/org and

patch -p 2 < changes-in-org-lisp.patch

Watch for conflicts.

Repeat for `doc' and other directories to be synched.

Review the changes with `bzr diff' and commit.

There should be no conflicts if you previously followed the same
procedure but in the Emacs -> Org direction.

Re: patch vs. overwrite in bzr

[David Engster]

Bastien writes:
> Óscar Fuentes <ofv@wanadoo.es> writes:
>> Stefan's advice has nothing to do with bzr. It is about not blindly
>> overwriting changes made on the emacs repo with the new version of the
>> externally-maintained package (`Org' is in this case.) Applying a patch
>> gives a lot more opportunities for noticing conflicts (suppossing that
>> the hacker cares to examine the output of the patch command, that is.)
>
> The problem is: how to create a patch from Org git repo that can be
> easily applied to Emacs bzr repo.
>
> If someone can come up with a workable solution, that'd help me a lot.
>
> Oscar, you said:
>
>> I suggest that, before syncing, you obtain a diff from the bzr (or git)
>> emacs repo that contains all changes to org since your last sync, commit
>> the diff onto your org sources and then proceed with the new sync.
>
> Which is theoretically fine... but if someone can actually *test* the
> suggested workflow, I'm all ears.

I'm in the process of writing a merge tool cedet-emacs-merge.el
('ceemme') for the upcoming CEDET/Emacs merges. You can find a very
rough first revision in our 'newtrunk':

http://cedet.bzr.sourceforge.net/bzr/cedet/code/newtrunk/files

Now, it clearly cannot be used straight away for org, since we're using
bzr and there are some very CEDET specific things in the code when
adapting paths and stuff like that, but it might give you an idea how
I'm planning to do things. Again: it's very early and I'm not using it
in production yet (will happen when Eric has released the current trunk
as 1.1).

In a nutshell: It's more or less a GUI to do cherry picking with bzr and
marking commits as 'applied', 'ignored' etc. and saving that state in
the repository between sessions. In the end it will work in both
directions, but currently I'm concentrating on the Emacs -> CEDET, since
this will be the first thing to do next. Also, for the other direction
we will probably use a dedicated branch like 'for-emacs' or something
like that and not directly push into Emacs.

If you or someone else would be interested into making this into a more
generic cross-project merge tool - I am all ears. However, I could also
imagine that there might be some git-trickery using submodules or
whatever which allows a more elegant workflow.

-David

Re: patch vs. overwrite in bzr [was: Next pretest, and regressions policy]

[Stefan Monnier]

> The problem is: how to create a patch from Org git repo that can be
> easily applied to Emacs bzr repo.

Remember somewhere which was the last revision of Org that was sync'd to
Emacs, and then create the patch by diffing against that revision.


        Stefan


PS: And after applying the patch, update the place where you remember the
last revision sync'd.

Re: patch vs. overwrite in bzr

[Stefan Monnier]

> In a nutshell: It's more or less a GUI to do cherry picking with bzr and
> marking commits as 'applied', 'ignored' etc. and saving that state in
> the repository between sessions. In the end it will work in both
> directions, but currently I'm concentrating on the Emacs -> CEDET, since
> this will be the first thing to do next. Also, for the other direction
> we will probably use a dedicated branch like 'for-emacs' or something
> like that and not directly push into Emacs.

The Gnus guys also do two-way syncing and have to solve the same
problem.  A generic tool would be awesome.  I think two-way syncing of
branches is a major problem with current VCS technology and I'm eagerly
awaiting a good generic solution to it.  I'm sure I'm not the only one.
Even better if it can be run from a cron job (i.e. fully automatic and
deals with conflicts somehow (obviously, it can't resolve them, so it
needs to store them somewhere, make sure someone will see them and will
be able to resolve them, ...)).


        Stefan

Re: patch vs. overwrite in bzr

[Glenn Morris]

Stefan Monnier wrote:

> Remember somewhere which was the last revision of Org that was sync'd to
> Emacs, and then create the patch by diffing against that revision.

As was said last time this happened (which is basically every time):

http://lists.gnu.org/archive/html/emacs-devel/2011-08/msg00648.html

Re: patch vs. overwrite in bzr

[Michael Albinus]

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

> The Gnus guys also do two-way syncing and have to solve the same
> problem.  A generic tool would be awesome.

1+. Tramp.

>         Stefan

Best regards, Michael.

Re: patch vs. overwrite in bzr

[Bastien]

Glenn Morris <rgm@gnu.org> writes:

> Stefan Monnier wrote:
>
>> Remember somewhere which was the last revision of Org that was sync'd to
>> Emacs, and then create the patch by diffing against that revision.
>
> As was said last time this happened (which is basically every time):
>
> http://lists.gnu.org/archive/html/emacs-devel/2011-08/msg00648.html

True.

I already complained about two things: the lack of mechanism to
systematically send commits about a module (org/gnus/tramp) to the
maintainer of this module; the lack of visibility for the release
schedule.

Both problems create additional work.

The first one because I need to watch the emacs-diffs mailing list
carefully and backport small commits to Org (80% of the last 67 commits
in the last 480 days were just useful but trivial commits).  To improve
the situation we could have 3-4 Emacs hackers directly committing in Org
while the maintainer focuses on syncing regularily.

The second one because it forces us to maintain a separate branch in
Org's repo, the one that corresponds to the current Emacs trunk.  I
already suggested a possible improvement (not a solution) about this:
have a different feature freeze window for modules and for Emacs core,
but got 0 answer.

Now that I'm thru with complaining, I 100% acknowledge my laziness in
setting up a good process for the 2-way sync.  But I will.  I'll see if
it works over time.

Finally, I'm curious to know whether you, Juanma and Paul would be
willing to commit fixes directly in the "hotfix" branch of Org's git.
This is the branch that is sync'ed with Emacs trunk, and committing
small fixes there first would remove 90% of the pain.

-- 
 Bastien

Re: patch vs. overwrite in bzr

[Glenn Morris]

Bastien wrote:

> Finally, I'm curious to know whether you, Juanma and Paul would be
> willing to commit fixes directly in the "hotfix" branch of Org's git.
> This is the branch that is sync'ed with Emacs trunk, and committing
> small fixes there first would remove 90% of the pain.

Thanks for the offer, but speaking for myself, no. I gave up making any
changes to Org, other than copyright-related ones. That isn't hard to
get right (just pay attention when adding new files that the headers
look the same as every other file in Emacs), so anyone can do it, if
they care to.

Re: patch vs. overwrite in bzr

[Stefan Monnier]

> I already suggested a possible improvement (not a solution) about
> this: have a different feature freeze window for modules and for Emacs
> core, but got 0 answer.

I may have replied elsewhere.  The way I see it, Org should be taken out
of `trunk' and instead the Emacs release should include a set of ELPA
packages (including Org).

> Finally, I'm curious to know whether you, Juanma and Paul would be
> willing to commit fixes directly in the "hotfix" branch of Org's git.
> This is the branch that is sync'ed with Emacs trunk, and committing
> small fixes there first would remove 90% of the pain.

If you let people commit to that branch it might become more difficult
to use it for the sync.


        Stefan

Re: patch vs. overwrite in bzr

[Bastien]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Finally, I'm curious to know whether you, Juanma and Paul would be
>> willing to commit fixes directly in the "hotfix" branch of Org's git.
>> This is the branch that is sync'ed with Emacs trunk, and committing
>> small fixes there first would remove 90% of the pain.
>
> If you let people commit to that branch it might become more difficult
> to use it for the sync.

Why?  E.g. If Paul committed spelling fixes to the hotfix branch of Org,
then merging this branch to Emacs would trigger less merge conflicts.

It doesn't remove the need for double-checking and for committing
patches instead of overwriting files, but it certainly alleviate the
maintainance burden.

I must be missing something.

-- 
 Bastien

Re: patch vs. overwrite in bzr

[Bastien]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I already suggested a possible improvement (not a solution) about
>> this: have a different feature freeze window for modules and for Emacs
>> core, but got 0 answer.
>
> I may have replied elsewhere.  The way I see it, Org should be taken out
> of `trunk' and instead the Emacs release should include a set of ELPA
> packages (including Org).

If people continue fixing things in ELPA instead of fixing them in Org,
we have the same 2-way sync challenge.

IMHO this move would just send a signal to Emacs devs "do not try to 
fix this, it's just an ELPA package" -- which does not so good to me.

I'd rather stick to the current situation where I get blamed for my
laziness in merging "the proper way", while still having vigilant people
like Glenn, Paul, Juanma and others fixing stuff in Org :)

After all, Org is in a pretty good shape right now in trunk.

-- 
 Bastien

Re: patch vs. overwrite in bzr

[Michael Albinus]

Bastien <bzg@gnu.org> writes:

>> I may have replied elsewhere.  The way I see it, Org should be taken out
>> of `trunk' and instead the Emacs release should include a set of ELPA
>> packages (including Org).
>
> IMHO this move would just send a signal to Emacs devs "do not try to 
> fix this, it's just an ELPA package" -- which does not so good to me.

I share the same fear that a package residing in the elpa branch could
be regarded as second class citizen. OTOH, being an elpa package would
require from us (external) package maintainers shorter freeze windows,
before a new Emacs release is shipped. New Tramp features are stalled
from being synced since June. A similar freeze period was before
releasing Emacs 23.

And in the Emacs 22 case, the freeze was for about 3 years, if I'm not
totally wrong. But maybe I'm just a too pedantic German, following every
freeze policy ...

Best regards, Michael.

Re: patch vs. overwrite in bzr

[Thierry Volpiatto]

Michael Albinus <michael.albinus@gmx.de> writes:

> Bastien <bzg@gnu.org> writes:
>
>>> I may have replied elsewhere.  The way I see it, Org should be taken out
>>> of `trunk' and instead the Emacs release should include a set of ELPA
>>> packages (including Org).
>>
>> IMHO this move would just send a signal to Emacs devs "do not try to 
>> fix this, it's just an ELPA package" -- which does not so good to me.
>
> I share the same fear that a package residing in the elpa branch could
> be regarded as second class citizen. OTOH, being an elpa package would
> require from us (external) package maintainers shorter freeze windows,
> before a new Emacs release is shipped. New Tramp features are stalled
> from being synced since June. A similar freeze period was before
> releasing Emacs 23.
>
> And in the Emacs 22 case, the freeze was for about 3 years, if I'm not
> totally wrong. But maybe I'm just a too pedantic German, following every
> freeze policy ...
I never understood why Emacs have not a developing branch to continue
developing new features during the feature freeze.
I think Emacs lost a lot a new features during this process, especially
from contributors that send patches; most patches are lost or
are unusable after several months of modifications in trunk.

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: patch vs. overwrite in bzr

[Stefan Monnier]

>>> I already suggested a possible improvement (not a solution) about
>>> this: have a different feature freeze window for modules and for Emacs
>>> core, but got 0 answer.
>> I may have replied elsewhere.  The way I see it, Org should be taken out
>> of `trunk' and instead the Emacs release should include a set of ELPA
>> packages (including Org).
> If people continue fixing things in ELPA instead of fixing them in Org,
> we have the same 2-way sync challenge.

Yes, 2-way syncin is another issue, one that we need to solve rather
than get rid of.

> IMHO this move would just send a signal to Emacs devs "do not try to
> fix this, it's just an ELPA package" -- which does not so good to me.

I'd like the `elpa' branch to become more integrated in Emacs so more
developers contribute to it just like they would with bundled packages.
We're not there yet, tho, obviously.


        Stefan

Re: patch vs. overwrite in bzr

[Stefan Monnier]

> I never understood why Emacs have not a developing branch to continue
> developing new features during the feature freeze.

This is because we do not believe we have the manpower to keep two
active branches, and that most people would just keep on using the
`trunk' rather than help debug the feature-frozen branch.

Whether this belief is warranted, I do not know, sadly.
I would be open to experiment with the alternative,


        Stefan

Re: patch vs. overwrite in bzr

[Jordi Gutiérrez Hermoso]

On 4 April 2012 09:20, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> I never understood why Emacs have not a developing branch to continue
>> developing new features during the feature freeze.
>
> This is because we do not believe we have the manpower to keep two
> active branches, and that most people would just keep on using the
> `trunk' rather than help debug the feature-frozen branch.
>
> Whether this belief is warranted, I do not know, sadly.
> I would be open to experiment with the alternative,

From one gnu to another, I think you should experiment. In Octave,
during release time we merge dev to stable, everyone regularly builds
stable, RC tarballs get released, people build them and report them,
and eventually the grand stable release is made, which is still
maintained in a separate stable branch. Meanwhile, dev goes on its
merry way, reguarly getting merged from stable, and people who don't
care about release schedules keep playing in dev.

Octave has a much smaller dev community than Emacs, and it seems to work for us.

- Jordi G. H.

Re: patch vs. overwrite in bzr

[Paul Eggert]

On 04/04/2012 06:20 AM, Stefan Monnier wrote:
> This is because we do not believe we have the manpower to keep two
> active branches, and that most people would just keep on using the
> `trunk' rather than help debug the feature-frozen branch.

As it happens I made a similar point in a lecture in my undergrad
software engineering course yesterday, and used Emacs 24 development
as the example!  Real-world software engineering often differs from
textbook assumptions of unlimited development resources.

> I would be open to experiment with the alternative,

If the trunk were unfrozen, I confess that I'd probably make almost all
my changes to the trunk.  Debugging is less fun, at least for this
volunteer.  But the alternative might be a good idea anyway, as
it might encourage more contributions overall while maintaining
an acceptably low defect rate in the production version.

Re: patch vs. overwrite in bzr

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 04 Apr 2012 09:16:46 -0400
> Cc: emacs-devel@gnu.org
> 
> Yes, 2-way syncin is another issue, one that we need to solve rather
> than get rid of.

If someone could describe the use cases and the requirements and post
that to the bzr mailing list, perhaps we could get some good advice
there, or maybe some useful plugins.

Re: patch vs. overwrite in bzr

[Eli Zaretskii]

> From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
> Date: Wed, 04 Apr 2012 10:35:34 +0200
> 
> I never understood why Emacs have not a developing branch to continue
> developing new features during the feature freeze.

Read the archives for past discussions of this issue, and you will
understand.  The reason is insufficient resources.  It takes a
significant effort to run a pretest, triage the bugs and fix important
ones, update the manuals, etc.  The extremely small number of core
maintainers does not leave resources to overview both the branch and
the trunk, as long as there's lots of work on each one of them.

People who want this to change should volunteer to do the tasks that
are needed to be done for the pretest and release.  Then 2 things will
happen: (1) there will be more people who can take a responsibility
for a release, thus freeing more time for the head maintainers to take
care of the trunk; and (2) the number of people who are familiar with
Emacs enough to become core maintainers will also grow.

> I think Emacs lost a lot a new features during this process, especially
> from contributors that send patches; most patches are lost or
> are unusable after several months of modifications in trunk.

If you use bzr or any other dVCS, you can simply put your changes on a
branch or even a shelf, and then when the time comes to push them, you
will have much less trouble than you think.  Modern VCSes do a very
good job at merging.

Re: patch vs. overwrite in bzr [was: Next pretest, and regressions policy]

[Eli Zaretskii]

> From: Bastien <bzg@gnu.org>
> Date: Tue, 03 Apr 2012 15:42:24 +0200
> Cc: emacs-devel@gnu.org
> 
> The problem is: how to create a patch from Org git repo that can be
> easily applied to Emacs bzr repo.
> 
> If someone can come up with a workable solution, that'd help me a lot.

Can you describe your current workflow in this respect?  I mean, the
last thing you probably want to hear is a suggestion for a workflow
that you already use, albeit imperfectly...

Re: patch vs. overwrite in bzr

[Thierry Volpiatto]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
>> Date: Wed, 04 Apr 2012 10:35:34 +0200
>> 
>> I never understood why Emacs have not a developing branch to continue
>> developing new features during the feature freeze.
>
> Read the archives for past discussions of this issue, and you will
> understand.  The reason is insufficient resources.  It takes a
> significant effort to run a pretest, triage the bugs and fix important
> ones, update the manuals, etc.  The extremely small number of core
> maintainers does not leave resources to overview both the branch and
> the trunk, as long as there's lots of work on each one of them.
You should not have to overview the dev branch, only the trunk and merge
regularly it in the dev branch. You would have only to review the
patches before applying to dev branch, but that's what you already do I
think. The difference is just that actually you say, yes patch is ok we
will apply it after feature freeze. Instead you would just have to apply 
if ok.


> People who want this to change should volunteer to do the tasks that
> are needed to be done for the pretest and release.  Then 2 things will
> happen: (1) there will be more people who can take a responsibility
> for a release, thus freeing more time for the head maintainers to take
> care of the trunk; and (2) the number of people who are familiar with
> Emacs enough to become core maintainers will also grow.
>
>> I think Emacs lost a lot a new features during this process, especially
>> from contributors that send patches; most patches are lost or
>> are unusable after several months of modifications in trunk.
>
> If you use bzr or any other dVCS, you can simply put your changes on a
> branch or even a shelf, and then when the time comes to push them, you
> will have much less trouble than you think.  Modern VCSes do a very
> good job at merging.
I know this, I use patches that I can pop and push again after pulling
last changes upstream.


-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: patch vs. overwrite in bzr [was: Next pretest, and regressions policy]

[Thierry Volpiatto]

> The problem is: how to create a patch from Org git repo that can be
> easily applied to Emacs bzr repo.

Org git repo ==> convert to mercurial ==> clone to mercurial qpatch
                                          make your changes here
                                          and apply the resulting(s)
                                          patche(s) to Emacs bzr repo.

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: patch vs. overwrite in bzr

[Stefan Monnier]

>> Yes, 2-way syncin is another issue, one that we need to solve rather
>> than get rid of.
> If someone could describe the use cases and the requirements and post
> that to the bzr mailing list, perhaps we could get some good advice
> there, or maybe some useful plugins.

Last time I posted about it (several years ago), it didn't elicit
much reaction.

IIUC it's just difficult to do it "right" because it's largely
incompatible with the way metadata/history is kept.  The best you can
get is good support for two-way sync between identical branches (which is
what we all use, where one of the branch is local to our machine and
the other is on bzr.sv.gnu.org), but as soon as the two branches are
supposed to be different the model breaks down.

The problem is similar to cherry-picking, but reversed: you want to be
able to get all changes except for a few negative-cherrypicks.  E.g,
"pull/merge from the Org branch all changes except for those few ones we
don't want" (and inversely, they want to "pull from the Emacs branch,
except for the file-renamings they did to adapt to their directory
layout").

Since the currently supported metadata can't be used, the solution ends
up having to be "manual" and can probably work equally well for most
VCS.  E.g. keep "tags" on both branches that record the last sync, and
when a new sync is attempted, get the diff since last sync on each
branch (using the tags), apply the patch to the other branch, commit and
update the tags.


        Stefan

Re: patch vs. overwrite in bzr

[Eli Zaretskii]

> From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
> Date: Wed, 04 Apr 2012 19:53:53 +0200
> 
> You should not have to overview the dev branch, only the trunk and merge
> regularly it in the dev branch. You would have only to review the
> patches before applying to dev branch, but that's what you already do I
> think. The difference is just that actually you say, yes patch is ok we
> will apply it after feature freeze. Instead you would just have to apply 
> if ok.

Not true.  There's a difference between doing a triage and actually
considering the patch for inclusion.  In addition, "overviewing" means
discussing design and implementation for significant contributions.
Development is not just patch reviews, at least not in Emacs.

> >> I think Emacs lost a lot a new features during this process, especially
> >> from contributors that send patches; most patches are lost or
> >> are unusable after several months of modifications in trunk.
> >
> > If you use bzr or any other dVCS, you can simply put your changes on a
> > branch or even a shelf, and then when the time comes to push them, you
> > will have much less trouble than you think.  Modern VCSes do a very
> > good job at merging.
> I know this, I use patches that I can pop and push again after pulling
> last changes upstream.

Then why do you present patch-rot as a significant factor?  It isn't.

Re: patch vs. overwrite in bzr

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: bzg@gnu.org,  emacs-devel@gnu.org
> Date: Wed, 04 Apr 2012 14:07:25 -0400
> 
> IIUC it's just difficult to do it "right" because it's largely
> incompatible with the way metadata/history is kept.  The best you can
> get is good support for two-way sync between identical branches (which is
> what we all use, where one of the branch is local to our machine and
> the other is on bzr.sv.gnu.org), but as soon as the two branches are
> supposed to be different the model breaks down.
> 
> The problem is similar to cherry-picking, but reversed: you want to be
> able to get all changes except for a few negative-cherrypicks.  E.g,
> "pull/merge from the Org branch all changes except for those few ones we
> don't want" (and inversely, they want to "pull from the Emacs branch,
> except for the file-renamings they did to adapt to their directory
> layout").

Would the problem be solved if such cherry-picking weren't needed?
That is, if the branches were exactly identical, but kept in two
different VCSes?  If this would solve the problem, then that's what
I'd suggest doing.  After all, all those differences sound very minor;
e.g., why not rename the files as the other guy does?

> Since the currently supported metadata can't be used, the solution ends
> up having to be "manual" and can probably work equally well for most
> VCS.  E.g. keep "tags" on both branches that record the last sync, and
> when a new sync is attempted, get the diff since last sync on each
> branch (using the tags), apply the patch to the other branch, commit and
> update the tags.

Did anyone consider using bzr-git as part of this?  It doesn't yet
support pushing to a git repo, but it does support "dpush", which
could be good enough.  And, of course, pulling from a git repository
is fully supported.

Re: patch vs. overwrite in bzr

[Thierry Volpiatto]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
>> Date: Wed, 04 Apr 2012 19:53:53 +0200
>> 
>> You should not have to overview the dev branch, only the trunk and merge
>> regularly it in the dev branch. You would have only to review the
>> patches before applying to dev branch, but that's what you already do I
>> think. The difference is just that actually you say, yes patch is ok we
>> will apply it after feature freeze. Instead you would just have to apply 
>> if ok.
>
> Not true.  There's a difference between doing a triage and actually
> considering the patch for inclusion.  In addition, "overviewing" means
> discussing design and implementation for significant contributions.
> Development is not just patch reviews, at least not in Emacs.
You are already doing this, so it is not extra work.

>> >> I think Emacs lost a lot a new features during this process, especially
>> >> from contributors that send patches; most patches are lost or
>> >> are unusable after several months of modifications in trunk.
>> >
>> > If you use bzr or any other dVCS, you can simply put your changes on a
>> > branch or even a shelf, and then when the time comes to push them, you
>> > will have much less trouble than you think.  Modern VCSes do a very
>> > good job at merging.
>> I know this, I use patches that I can pop and push again after pulling
>> last changes upstream.
>
> Then why do you present patch-rot as a significant factor?
Most people don't want to do this and just do not contribute, so you
lose many potentials contributors.

> It isn't.
It is actually not easy to contribute to Emacs.

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: patch vs. overwrite in bzr

[David Engster]

Eli Zaretskii writes:
>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> The problem is similar to cherry-picking, but reversed: you want to be
>> able to get all changes except for a few negative-cherrypicks.  E.g,
>> "pull/merge from the Org branch all changes except for those few ones we
>> don't want" (and inversely, they want to "pull from the Emacs branch,
>> except for the file-renamings they did to adapt to their directory
>> layout").
>
> Would the problem be solved if such cherry-picking weren't needed?
> That is, if the branches were exactly identical, but kept in two
> different VCSes?  If this would solve the problem, then that's what
> I'd suggest doing.  After all, all those differences sound very minor;
> e.g., why not rename the files as the other guy does?

At least for CEDET, I can surely tell that we won't get fully identical
branches, at least not in the foreseeable future. This is mainly due to

- compatibility code we keep for older Emacs versions (we will drop
  Emacs22 support for our new development branch, but there are still
  things like cedet-called-interactively-p for Emacs 23.1),

- features that currently depend on defadvice or other hacks, but that
  are very useful for hacking on CEDET (generating properly linked help
  buffers for EIEIO methods and classes, for instance),

- minor packages which are not needed or wanted in Emacs proper (like
  COGRE),

- things we don't have papers for and are in our contrib directory,

- EIEIO is part of CEDET but not in lisp/cedet but in lisp/emacs-lisp (a
  similar problem exists with Speedbar, but that is in Emacs for quite
  some time now and most development happens there anyway).

It's not as bad as it sounds; most of the differences are minor or are
at least well separated, but still - you need to cherry-pick commits.

-David

Re: patch vs. overwrite in bzr

[Eli Zaretskii]

> From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Wed, 04 Apr 2012 21:38:39 +0200
> 
> > Not true.  There's a difference between doing a triage and actually
> > considering the patch for inclusion.  In addition, "overviewing" means
> > discussing design and implementation for significant contributions.
> > Development is not just patch reviews, at least not in Emacs.
> You are already doing this

Yes, but not on both branches simultaneously.

> Most people don't want to do this and just do not contribute, so you
> lose many potentials contributors.

I sincerely doubt that.

Re: patch vs. overwrite in bzr

[Stefan Monnier]

> Would the problem be solved if such cherry-picking weren't needed?

To a large extent, yes, but the cases we're talking about can't do that
(which is why we're talking about that).

> That is, if the branches were exactly identical, but kept in two
> different VCSes?  If this would solve the problem, then that's what
> I'd suggest doing.  After all, all those differences sound very minor;
> e.g., why not rename the files as the other guy does?

The `emacs' branch includes tons of other things that aren't in the
`org' branch for obvious reasons.

> Did anyone consider using bzr-git as part of this?

I started using it for some `elpa' packages, yes.  Using a different VCS
is not the problem: differences between the branches's contents is
the problem.


        Stefan

Re: patch vs. overwrite in bzr

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: bzg@gnu.org,  emacs-devel@gnu.org
> Date: Wed, 04 Apr 2012 18:06:19 -0400
> 
> > Would the problem be solved if such cherry-picking weren't needed?
> 
> To a large extent, yes, but the cases we're talking about can't do that
> (which is why we're talking about that).

If this is the primary reason for problems, then in my experience this
is the first problem to tackle.  Whatever the issues are that cause
the branches to be different, they should be regarded as secondary,
and solutions found for them that let the branches become not
different.

> > That is, if the branches were exactly identical, but kept in two
> > different VCSes?  If this would solve the problem, then that's what
> > I'd suggest doing.  After all, all those differences sound very minor;
> > e.g., why not rename the files as the other guy does?
> 
> The `emacs' branch includes tons of other things that aren't in the
> `org' branch for obvious reasons.

Why should Org maintainers care about things they don't need?  Let
them be there, they will do no harm at all.

Re: patch vs. overwrite in bzr [was: Next pretest, and regressions policy]

[Bastien]

Hi Eli,

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Bastien <bzg@gnu.org>
>> Date: Tue, 03 Apr 2012 15:42:24 +0200
>> Cc: emacs-devel@gnu.org
>> 
>> The problem is: how to create a patch from Org git repo that can be
>> easily applied to Emacs bzr repo.
>> 
>> If someone can come up with a workable solution, that'd help me a lot.
>
> Can you describe your current workflow in this respect?  I mean, the
> last thing you probably want to hear is a suggestion for a workflow
> that you already use, albeit imperfectly...

Org git repo has three branches:

- "maint"  = branch for releases only
- "hotfix" = branch for hotfixes against the current release
- "master" = the development branch

Hotfixes go to... hotfix, while ordinary development goes to master.
For minor releases, we merge hotfix to maint.  For major release, we
merge master to maint.  We add a release tag from maint.

For the Emacs sync:

So far, I *copied* files from the hotfix branch to Emacs, trying to
review the diff before committing (obviously my brain has been asleep
when I did this, and I relied too much on the assumption that I
correctly backported changes to Org in Emacs to the Org git repo.)

From now on, here is what I will try to do.

I have a local "emacs-merge" branch, stemming from hotfix.  This local
branch has a directory "emacs" that reproduce part of the hierarchy of
Emacs files, that part which contains Org files.

doc
 misc
  ChangeLog
  org.texi
etc
 org
  OrgOdtContentTemplate.xml
  OrgOdtStyles.xml
  README
 refcards
  orgcard.pdf
  orgcard.tex
lisp
 org
  ChangeLog
  [org/ob..el]x109

Then the sync process is this:

1. Check for org-related changes in Emacs trunk

2. Backport them to the hotfix branch

3. Copy the files from the hotfix branch to the emacs dir in my local
   emacs-merge branch, and get a diff from there.

4. Clean up the patch so that it applies correctly in Emacs trunk.

5. Fix merge conflicts in the hotfix branch and go back to 3 if needed.

6. Commit the diff on the "org" bzr branch (bound to the remote Emacs
   trunk) when things look fine.

Suggestions against this workflow are welcome.

-- 
 Bastien

Re: patch vs. overwrite in bzr [was: Next pretest, and regressions policy]

[Bastien]

Hi Thierry,

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

>> The problem is: how to create a patch from Org git repo that can be
>> easily applied to Emacs bzr repo.
>
> Org git repo ==> convert to mercurial ==> clone to mercurial qpatch
>                                           make your changes here
>                                           and apply the resulting(s)
>                                           patche(s) to Emacs bzr repo.

Please test this workflow *for real* and tell me if this is workable.

Thanks,

-- 
 Bastien

Re: patch vs. overwrite in bzr [was: Next pretest, and regressions policy]

[Thierry Volpiatto]

Bastien <bzg@gnu.org> writes:

> Hi Thierry,
>
> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>
>>> The problem is: how to create a patch from Org git repo that can be
>>> easily applied to Emacs bzr repo.
>>
>> Org git repo ==> convert to mercurial ==> clone to mercurial qpatch
>>                                           make your changes here
>>                                           and apply the resulting(s)
>>                                           patche(s) to Emacs bzr repo.
>
> Please test this workflow *for real* and tell me if this is workable.

Of course, the "Org git repo" should be the same beast as what is in 
"Emacs bzr repo" which is not the case.

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: patch vs. overwrite in bzr

[Stefan Monnier]

>> The `emacs' branch includes tons of other things that aren't in the
>> `org' branch for obvious reasons.
> Why should Org maintainers care about things they don't need?  Let
> them be there, they will do no harm at all.

That amounts to using the Emacs repository is the canonical repository
for Gnus, ERC, CEDET, MH-E, Org, ...
But they don't want to do that, often for good reasons (legal,
practical, ...).


        Stefan

Re: patch vs. overwrite in bzr

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> That amounts to using the Emacs repository is the canonical repository
> for Gnus, ERC, CEDET, MH-E, Org, ...
> But they don't want to do that, often for good reasons (legal,
> practical, ...).

I would guess that the main practical reason for having the external
repositories is the long feature freeze that happens in Emacs
development.

If Emacs shifted to a "continuous development" model (with branches
being forked off for stabilisation now and then), that might change
... stuff.  That might not be practical, though, as previously pointed
out.  Virtually all the developers would "live" in the trunk version of
Emacs, so the forked-off stable version would get less love and testing.

I don't know.  Would it be worth trying to shifting to that model after
Emacs 24.1?  Preferably with more frequent releases, too.  :-)

The other practical consideration, though, is that several (some? all?)
of the packages mentioned also contains code not relevant for the
current Emacs -- compatibility stuff, XEmacs stuff, etc.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: patch vs. overwrite in bzr [was: Next pretest, and regressions policy]

[Eli Zaretskii]

> From: Bastien <bzg@gnu.org>
> Cc: ofv@wanadoo.es,  emacs-devel@gnu.org
> Date: Thu, 05 Apr 2012 09:13:09 +0200
> 
> I have a local "emacs-merge" branch, stemming from hotfix.  This local
> branch has a directory "emacs" that reproduce part of the hierarchy of
> Emacs files, that part which contains Org files.
> 
> doc
>  misc
>   ChangeLog
>   org.texi
> etc
>  org
>   OrgOdtContentTemplate.xml
>   OrgOdtStyles.xml
>   README
>  refcards
>   orgcard.pdf
>   orgcard.tex
> lisp
>  org
>   ChangeLog
>   [org/ob..el]x109
> 
> Then the sync process is this:
> 
> 1. Check for org-related changes in Emacs trunk
> 
> 2. Backport them to the hotfix branch
> 
> 3. Copy the files from the hotfix branch to the emacs dir in my local
>    emacs-merge branch, and get a diff from there.
> 
> 4. Clean up the patch so that it applies correctly in Emacs trunk.
> 
> 5. Fix merge conflicts in the hotfix branch and go back to 3 if needed.
> 
> 6. Commit the diff on the "org" bzr branch (bound to the remote Emacs
>    trunk) when things look fine.
> 
> Suggestions against this workflow are welcome.

Well, I'm not sure I get all the details of your setup, so it's
possible that I will say something silly; apologies in advance.  But
IIUC, you could get away with less branches and less manual work.  So
here we go:

Setup:

  . A bound bzr branch, let's call it emacs-trunk, where you don't
    make any changes, just merge before committing upstream, to the
    Emacs master repository.

  . A local bzr branch, let's call it emacs-org, which will be the
    branch that you sync with one of your git branches.  From this
    branch you will merge to emacs-trunk before committing upstream.

  . A git branch that corresponds to emacs-org, I think this could be
    your hotfix branch, as I don't understand why you need the
    emacs-merge branch.

Below I assume that you have the bzr-tiplog plugin installed.  It
provides the functionality similar to git-reflog, and lets you skip
the error-prone step of remembering or keeping notes about the last
bzr revision you sync'ed with (see below); the only revision id's you
will ever need to remember is tip:0 and tip:1.

The sync process proceeds in cycles.  Each cycle begins when you sync
from Emacs repo to Org as follows:

  cd emacs-trunk
  bzr update
  cd ../emacs-org
  bzr merge --pull ../emacs-trunk

Now emacs-org is synchronized with the Emacs trunk.  Next, produce the
org-related changes since your last synchronization:

  bzr diff -r tip:1..tip:0 lisp/org > patches

(If there are files outside lisp/org that you are interested in,
perhaps etc/NEWS or doc/misc/org.texi, mention them as well; bzr will
produce diffs only for those files and directories, leaving out stuff
you don't care about.)

The file `patches' produced above includes files that are added,
removed, and renamed, but not in the form of diffs (I think).  So to
make sure you don't miss those changes, do also this:

  bzr status -r tip:1..tip:0 lisp/org

(again, add any other directories you are interested in), and examine
the output for any non-text changes.

Now sync your git branch, by (a) applying `patches' with Patch, and
(b) performing any file operations.  The latter should be done by
hand, or you could perhaps write some simple script to parse the
output of "bzr status" and do it for you.

After this, you develop Org normally.  I understand you have other
branches, so you probably will wish to use git commands to merge the
changes into them as well, and then back to the branch that you will
later sync with bzr.

I suggest to perform the steps above as frequent as you can, to avoid
diverging too much from the Emacs trunk.  That will make the second
part of the cycle easier.  I'd expect that more often than not, you
will find that no changes were done that pertain to Org, so I don't
think the burden will be too heavy.  The advantage is that your code
will be very similar to what the Emacs trunk has, so all your testing
will not need to be redone when you merge with the latest trunk below.

So time passes, and you decide you are ready to commit to the Emacs
repo.  Then, just overwrite the files in emacs-org with the
corresponding files in your git branch (using rsync or some such), and
type these bzr commands:

  cd emacs-org
  bzr commit -m "sync'ed with git revision 12345abcd"

You now have a bzr branch that is synchronized with your git branch.

Now find out how much you diverged from the trunk since the last
resync:

  cd ../emacs-trunk
  bzr update
  bzr diff -r branch:../emacs-org.. lisp/org

If the diffs this shows are insignificant enough, you can simply merge
into trunk and commit:

  bzr merge ../emacs-org
  bzr ci -m "Merge from Org repo."

If, however, enough time has passed since the last sync, and the diffs
are non-trivial, you will have to merge back to emacs-org and retest:

  cd ../emacs-org
  bzr merge ../emacs-trunk
  # build and test
  cd ../emacs-trunk
  bzr merge ../emacs-org
  bzr ci -m "Merge from Org repo."

This completes the cycle, and you are ready to begin the next one.

HTH

Re: patch vs. overwrite in bzr

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Date: Thu, 05 Apr 2012 17:24:37 +0200
> 
> If Emacs shifted to a "continuous development" model (with branches
> being forked off for stabilisation now and then), that might change
> ... stuff.  That might not be practical, though, as previously pointed
> out.  Virtually all the developers would "live" in the trunk version of
> Emacs, so the forked-off stable version would get less love and testing.
> 
> I don't know.  Would it be worth trying to shifting to that model after
> Emacs 24.1?

We could try, but I doubt it will work.  For it to work, we need
enough people on board to continuously take care of all the important
parts of the package (including the documentation and other mundane
tasks).  What happens now is that the same few need to do all of it,
which precludes the model you hope for.

Re: patch vs. overwrite in bzr

[Ted Zlatanov]

On Thu, 05 Apr 2012 17:24:37 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> That amounts to using the Emacs repository is the canonical repository
>> for Gnus, ERC, CEDET, MH-E, Org, ...
>> But they don't want to do that, often for good reasons (legal,
>> practical, ...).

LMI> I would guess that the main practical reason for having the external
LMI> repositories is the long feature freeze that happens in Emacs
LMI> development.

I would be very unhappy if Gnus switched from Git to Bazaar, and I
believe many Gnus and other packages' developers feel the same way.  For
me, at least, it's a bigger issue than the feature freezes or
the compatibility code.

Ted

Re: patch vs. overwrite in bzr

[Richard Stallman]

    That amounts to using the Emacs repository is the canonical repository
    for Gnus, ERC, CEDET, MH-E, Org, ...
    But they don't want to do that, often for good reasons (legal,
    practical, ...).

If there is a legal reason for this, doesn't that imply a problem of
some kind already exists?  We need to find out what the claimed legal
reasons are, and think about whether they indicate legal problems for
Emacs development.

As for practical reasons, doesn't the flexibility of a DVCS
make them go away?


--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: patch vs. overwrite in bzr

[Bastien]

Richard Stallman <rms@gnu.org> writes:

>     That amounts to using the Emacs repository is the canonical repository
>     for Gnus, ERC, CEDET, MH-E, Org, ...
>     But they don't want to do that, often for good reasons (legal,
>     practical, ...).

As I see it, the main reason for Org to use a separate repository
is to gather an active community around a central place.

Regular Org testers don't want to rebuild Emacs each time they have 
to test a new feature in Org.

The second main reason is completely subjective: I prefer git over 
bzr and I want to maintain Org using git.

> If there is a legal reason for this, doesn't that imply a problem of
> some kind already exists?  We need to find out what the claimed legal
> reasons are, and think about whether they indicate legal problems for
> Emacs development.

There is no legal reason for not using the Emacs repository as the
canonical repository for Org.  Just a practical one: doing so would
force us to maintain the canonical Org repository in Emacs *and* 
another repository for things that are useful to Org and that cannot
be part of Emacs.

> As for practical reasons, doesn't the flexibility of a DVCS
> make them go away?

Above legal (unknown) reasons, and above practical reasons, there
is this community-based argument I stated above, which is IMHO the
most important.

-- 
 Bastien

Re: patch vs. overwrite in bzr

[Eli Zaretskii]

> From: Bastien <bzg@gnu.org>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  eliz@gnu.org,  emacs-devel@gnu.org
> Date: Fri, 06 Apr 2012 10:29:13 +0200
> 
> Regular Org testers don't want to rebuild Emacs each time they have 
> to test a new feature in Org.

Why would they need to do that?  Org is not preloaded into Emacs, so
all you need is compile the new Org files and perhaps restart the
Emacs session, but not rebuild Emacs.

Re: patch vs. overwrite in bzr

[Eli Zaretskii]

> Date: Fri, 06 Apr 2012 03:13:09 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: eliz@gnu.org, bzg@gnu.org, emacs-devel@gnu.org
> 
> As for practical reasons, doesn't the flexibility of a DVCS
> make them go away?

It probably would, except that most of those projects don't use
Bazaar.  There are no ways (AFAIK) to sync on a day-to-day basis 2
repositories maintained by 2 different VCSes.  By contrast, there
_are_ several potential solutions if you use a single dVCS.  Git
supports nested repositories (IIUC), and bzr has a couple of plugins
to do something similar.

Re: patch vs. overwrite in bzr

[Bastien]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Bastien <bzg@gnu.org>
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  eliz@gnu.org,  emacs-devel@gnu.org
>> Date: Fri, 06 Apr 2012 10:29:13 +0200
>> 
>> Regular Org testers don't want to rebuild Emacs each time they have 
>> to test a new feature in Org.
>
> Why would they need to do that?  Org is not preloaded into Emacs, so
> all you need is compile the new Org files and perhaps restart the
> Emacs session, but not rebuild Emacs.

Right.  But there are other problems.  

- Updating to the latest Org via `bzr update' would take longer compared
  to the current `git pull' (several factors here...)

- Some people don't have access to their Emacs installation (at work,
  for example) and still want the latest Org.

And surely more.  In any case, I'm all in favor of having the most
recent Org in Emacs trunk regularily, but migrating the development
of Org from the separate git repo to Emacs bzr repo is a no-go.

-- 
 Bastien

Re: patch vs. overwrite in bzr

[Eli Zaretskii]

> From: Bastien <bzg@gnu.org>
> Cc: rms@gnu.org,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Fri, 06 Apr 2012 11:20:18 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Bastien <bzg@gnu.org>
> >> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  eliz@gnu.org,  emacs-devel@gnu.org
> >> Date: Fri, 06 Apr 2012 10:29:13 +0200
> >> 
> >> Regular Org testers don't want to rebuild Emacs each time they have 
> >> to test a new feature in Org.
> >
> > Why would they need to do that?  Org is not preloaded into Emacs, so
> > all you need is compile the new Org files and perhaps restart the
> > Emacs session, but not rebuild Emacs.
> 
> Right.  But there are other problems.  
> 
> - Updating to the latest Org via `bzr update' would take longer compared
>   to the current `git pull' (several factors here...)

Like what?  And how much faster is "faster"?

I believe this is just the general git-preference issue, which has
nothing to do with "faster".

> - Some people don't have access to their Emacs installation (at work,
>   for example) and still want the latest Org.

Well, that's what site-lisp and/or load-path are for, right?  That's
how those users install Org right now anyway, I believe.  They can
continue doing that if Org were to be maintained as part of the Emacs
repository.

> And surely more.  In any case, I'm all in favor of having the most
> recent Org in Emacs trunk regularily, but migrating the development
> of Org from the separate git repo to Emacs bzr repo is a no-go.

I understand, and I think this is the _only_ real issue involved.

Re: patch vs. overwrite in bzr

[Bastien]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Bastien <bzg@gnu.org>
>> Cc: rms@gnu.org,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
>> Date: Fri, 06 Apr 2012 11:20:18 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: Bastien <bzg@gnu.org>
>> >> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  eliz@gnu.org,  emacs-devel@gnu.org
>> >> Date: Fri, 06 Apr 2012 10:29:13 +0200
>> >> 
>> >> Regular Org testers don't want to rebuild Emacs each time they have 
>> >> to test a new feature in Org.
>> >
>> > Why would they need to do that?  Org is not preloaded into Emacs, so
>> > all you need is compile the new Org files and perhaps restart the
>> > Emacs session, but not rebuild Emacs.
>> 
>> Right.  But there are other problems.  
>> 
>> - Updating to the latest Org via `bzr update' would take longer compared
>>   to the current `git pull' (several factors here...)
>
> Like what?  And how much faster is "faster"?

Like "significantly for my own usage".

Check this source for a comparison:
http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html#high-storage-efficiency-and-speed

Git might be slower on Windows, though.

I think nobody really disagree with git being faster. 

> I believe this is just the general git-preference issue, which has
> nothing to do with "faster".

Sorry to disagree.  And it's a key factor, especially for small projects 
that you want to follow/help occasionally.

>> - Some people don't have access to their Emacs installation (at work,
>>   for example) and still want the latest Org.
>
> Well, that's what site-lisp and/or load-path are for, right?  That's
> how those users install Org right now anyway, I believe.  They can
> continue doing that if Org were to be maintained as part of the Emacs
> repository.

You suggest Org testers should clone Emacs and add the relevant
load-path in their setup, just to be able to test Org?  Mhh.. doesn't 
look really sexy to me.

>> And surely more.  In any case, I'm all in favor of having the most
>> recent Org in Emacs trunk regularily, but migrating the development
>> of Org from the separate git repo to Emacs bzr repo is a no-go.
>
> I understand, and I think this is the _only_ real issue involved.

Since I agree this is the main one, I won't argue about the other 
issues anyway :)  And I guess we all have too much to do to argue
on such things.  

Looking forward,

-- 
 Bastien

Re: patch vs. overwrite in bzr

[Christophe Poncy]

On Fri, 06 Apr 2012 11:40:18 +0300, Eli Zaretskii wrote:
>> From: Bastien <bzg@gnu.org>
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  eliz@gnu.org,  
>> emacs-devel@gnu.org
>> Date: Fri, 06 Apr 2012 10:29:13 +0200
>>
>> Regular Org testers don't want to rebuild Emacs each time they have
>> to test a new feature in Org.
>
> Why would they need to do that?  Org is not preloaded into Emacs, so
> all you need is compile the new Org files and perhaps restart the
> Emacs session, but not rebuild Emacs.


It's so easy and convenient to get their latest development release 
from their git repo. I must confess that I like this way to stay up to 
date. I would love to do the same with emacs ;)

Re: patch vs. overwrite in bzr

[Eli Zaretskii]

> Date: Fri, 06 Apr 2012 18:17:42 +0200
> From: Christophe Poncy <cp@canaxis.org>
> 
> It's so easy and convenient to get their latest development release 
> from their git repo. I must confess that I like this way to stay up to 
> date. I would love to do the same with emacs ;)

What is missing to allow you to do the same with Emacs?

Re: patch vs. overwrite in bzr

[Christophe Poncy]

On Fri, 06 Apr 2012 19:41:06 +0300, Eli Zaretskii wrote:
>> Date: Fri, 06 Apr 2012 18:17:42 +0200
>> From: Christophe Poncy <cp@canaxis.org>
>>
>> It's so easy and convenient to get their latest development release
>> from their git repo. I must confess that I like this way to stay up 
>> to
>> date. I would love to do the same with emacs ;)
>
> What is missing to allow you to do the same with Emacs?


probably my fault, I got an error message after some time and never 
tried again. I never had this sort of problem with git for all other 
programs I am using this way... I understand this is not the point of 
this thread, so I am really sorry Eli to talk about that...

Re: patch vs. overwrite in bzr

[chad]

On Apr 6, 2012, at 3:20 AM, Bastien wrote:
>> Like what?  And how much faster is "faster"?
> 
> Like "significantly for my own usage".
> 
> Check this source for a comparison:
> http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html#high-storage-efficiency-and-speed
> 
> Git might be slower on Windows, though.
> 
> I think nobody really disagree with git being faster. 

Both the Bazaar and git people agree that bazaar/git is faster than git/bazaar on some things and slower on others.  Eli is (I believe) curious about what things you're doing that seem importantly faster on git.  

The bazaar doc you reference says specifically this about speed:

	Git is faster but Bazaar is clearly fast enough for 99.9% of
	users. If Bazaar 2.x is genuinely too slow for you on your
	project, please tell us where and we’ll do what we can to fix
	the problem for you.

Like emacs versus vi, this question has quite a lot of ``well-known knowledge'' that is widely spread, oft-quoted, and generally untrue.  That isn't meant to imply that your experience is invalid; simply to point out that `the common conception says...' is often well off the mark in this area.

> Since I agree this is the main one, I won't argue about the other 
> issues anyway :)  And I guess we all have too much to do to argue
> on such things.  

True, very true.  It is *perhaps* worth talking about as a `background task', though, because there are many VCS things that become much easier if two linked systems use the *same* dVCS, and Emacs seems very likely to stick with Bazaar for philosophical reasons.

I hope that helps,
*Chad

Re: patch vs. overwrite in bzr

[joakim]

chad <yandros@MIT.EDU> writes:

> On Apr 6, 2012, at 3:20 AM, Bastien wrote:
>>> Like what?  And how much faster is "faster"?
>> 
>> Like "significantly for my own usage".
>> 
>> Check this source for a comparison:
>> http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html#high-storage-efficiency-and-speed> 
>> Git might be slower on Windows, though.
>> 
>> I think nobody really disagree with git being faster. 
>
> Both the Bazaar and git people agree that bazaar/git is faster than git/bazaar on some things and slower on others.  Eli is (I believe) curious about what things you're doing that seem importantly faster on git.  
>
> The bazaar doc you reference says specifically this about speed:
>
> 	Git is faster but Bazaar is clearly fast enough for 99.9% of
> 	users. If Bazaar 2.x is genuinely too slow for you on your
> 	project, please tell us where and we’ll do what we can to fix
> 	the problem for you.
>
> Like emacs versus vi, this question has quite a lot of ``well-known knowledge'' that is widely spread, oft-quoted, and generally untrue.  That isn't meant to imply that your experience is invalid; simply to point out that `the common conception says...' is often well off the mark in this area.
>
>> Since I agree this is the main one, I won't argue about the other 
>> issues anyway :)  And I guess we all have too much to do to argue
>> on such things.  
>
> True, very true.  It is *perhaps* worth talking about as a `background task', though, because there are many VCS things that become much easier if two linked systems use the *same* dVCS, and Emacs seems very likely to stick with Bazaar for philosophical reasons.

I hesitate to inject more noise, but here goes anyway.

I use bzr for Emacs and Inkscape, Git for most other projects, Svn at
work.

Bzr is okay for most things, except it lacks co-located branches, and
has some bugs. I tried using the "loom" plugin for a while, but then the
repository format became incompatible with upstream. I tried the git-bzr
git plugin for a while but that didn't work too well because of bugs in
bzr fastimport. (these bugs are reported upstream)

The thing I would like to achieve in the Emacs case that is tedious with
bzr is to maintain a long lived branch(the emacs xwidgets branch),
together with some various patches, and use these as my local primary
Emacs. This workflow is pretty convenient in Git with colocated
branches. AFAIK it is a planned feature for Bzr but it's not ready yet.

I feel I provide less Emacs patches than I could because of this lack. I
would be interested to know how other Emacs developers handle this
situation. Perhaps there is something I am missing?



>
> I hope that helps,
> *Chad
>
>
>

-- 
Joakim Verona

Re: patch vs. overwrite in bzr

[Eli Zaretskii]

> From: joakim@verona.se
> Cc: Bastien <bzg@gnu.org>,  Eli Zaretskii <eliz@gnu.org>,  rms@gnu.org,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Fri, 06 Apr 2012 22:01:57 +0200
> 
> Bzr is okay for most things, except it lacks co-located branches

As of v2.5.0 (the latest stable release), bzr supports co-located
branches in the core, so no plugins are necessary.  (I didn't use it,
so I cannot share any experience.)

> I tried the git-bzr git plugin for a while but that didn't work too
> well because of bugs in bzr fastimport.

When did you last try that?  AFAIK, all the significant bugs are now
fixed, and in fact bzr-git is bundled with the official release.

For me, the main disadvantage of bzr-git is that the initial branch
(a.k.a. clone) command is painfully slow, because bzr needs to convert
all the git meta-data to bzr format.  (After the initial branch
creation, pulling is quite bearable.)  But other than that, its
integration with bzr is very good, and starting with bzr 2.5, you can
clone all the branches, not just master, and pull separately from each
branch.

> This workflow is pretty convenient in Git with colocated
> branches. AFAIK it is a planned feature for Bzr but it's not ready yet.

The future is here, see above.  You may wish to give it another try.

> I feel I provide less Emacs patches than I could because of this lack. I
> would be interested to know how other Emacs developers handle this
> situation. Perhaps there is something I am missing?

FWIW, I like having separate branches.  At least for Emacs, and for
the use case when the changes in the branch are significant (like what
I had for bidi), co-located branches get in the way because switching
branches needs to make a lot of changes, and requires a large build if
not a full bootstrap.  So having several branches sharing the same
tree does not gain much, and their disadvantage -- the possibility to
forget what branch is the current one and mess up -- is not worth that
gain.  YMMV, of course.

Re: patch vs. overwrite in bzr

[Juanma Barranquero]

On Fri, Apr 6, 2012 at 22:01,  <joakim@verona.se> wrote:

> Bzr is okay for most things, except it lacks co-located branches

From the 2.5.0 announcement: "The 2.5 series provides a faster smart
protocol implementation for many operations, basic support for
colocated branches."

So it's almost there.

    Juanma

Re: patch vs. overwrite in bzr

[Richard Stallman]

    As I see it, the main reason for Org to use a separate repository
    is to gather an active community around a central place.

    Regular Org testers don't want to rebuild Emacs each time they have 
    to test a new feature in Org.

Doesn't bzr allow them to do all the same things while
using the Emacs repository?

    There is no legal reason for not using the Emacs repository as the
    canonical repository for Org.  Just a practical one: doing so would
    force us to maintain the canonical Org repository in Emacs *and* 
    another repository for things that are useful to Org and that cannot
    be part of Emacs.

I am concerned that this practice is harmful.
Would we want these things to be part of Emacs?
If not, then it isn't a problem.
But if so, distributing them with Org in this way
is undermining our efforts.

--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: patch vs. overwrite in bzr

[Richard Stallman]

We use Bzr, and will continue to use Bzr, because that is a GNU
package and git is not.  GNU packages ought to help promote other GNU
packages, because they are all part of one larger project: the GNU
Project.

--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: patch vs. overwrite in bzr

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

[snip]

> FWIW, I like having separate branches.  At least for Emacs, and for
> the use case when the changes in the branch are significant (like what
> I had for bidi), co-located branches get in the way because switching
> branches needs to make a lot of changes, and requires a large build if
> not a full bootstrap.

Use out-of-source builds, with a build directory per branch... unless
that collides with Emacs' peculiar practice of putting build products on
the source tree for out-of-source builds.

On addition, when I switch branches from Emacs the relevant function is
advised for storing timestamps of the files of the current branch before
the switch and recover the timestamps of the new branch's files after
the switch, so no rebuild is triggered because some source file was
modified by the switch when the new branch already has an associated up
to date build.

> So having several branches sharing the same
> tree does not gain much, and their disadvantage -- the possibility to
> forget what branch is the current one and mess up -- is not worth that
> gain.
[snip]

vc-git solves this by displaying the current branch name on the
modeline. vc-bzr could do the same if colocated branches gain
popularity.

Re: patch vs. overwrite in bzr

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 07 Apr 2012 04:28:46 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> [snip]
> 
> > FWIW, I like having separate branches.  At least for Emacs, and for
> > the use case when the changes in the branch are significant (like what
> > I had for bidi), co-located branches get in the way because switching
> > branches needs to make a lot of changes, and requires a large build if
> > not a full bootstrap.
> 
> Use out-of-source builds, with a build directory per branch...

What for?  I have no problems with the above arrangement.  Joakim
asked how others arrange their branches, and I described mine.  There
are no problems I have that would require me to change it.

> unless that collides with Emacs' peculiar practice of putting build
> products on the source tree for out-of-source builds.

Nothing peculiar here: the Windows build simply doesn't support
out-of-source builds.  But I build inside the source tree on GNU/Linux
as well, so that's not the main reason.

> On addition, when I switch branches from Emacs the relevant function is
> advised for storing timestamps of the files of the current branch before
> the switch and recover the timestamps of the new branch's files after
> the switch, so no rebuild is triggered because some source file was
> modified by the switch when the new branch already has an associated up
> to date build.

IMO, this is a dangerous practice, because you cannot always
second-guess what needs to be rebuilt after the switch, what with all
the complex Makefile rules.

In any case, if you have branches in separate directories, you get
that for free.

> vc-git solves this by displaying the current branch name on the
> modeline. vc-bzr could do the same if colocated branches gain
> popularity.

You are assuming that I use VC to do my bzr operations.  That's false.

Re: patch vs. overwrite in bzr

[Andreas Schwab]

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

> On addition, when I switch branches from Emacs the relevant function is
> advised for storing timestamps of the files of the current branch before
> the switch and recover the timestamps of the new branch's files after
> the switch, so no rebuild is triggered because some source file was
> modified by the switch when the new branch already has an associated up
> to date build.

Whatfor?  git doesn't touch files that didn't change when checking out a
different revision.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: patch vs. overwrite in bzr

[Bastien]

Richard Stallman <rms@gnu.org> writes:

>     As I see it, the main reason for Org to use a separate repository
>     is to gather an active community around a central place.
>
>     Regular Org testers don't want to rebuild Emacs each time they have 
>     to test a new feature in Org.
>
> Doesn't bzr allow them to do all the same things while
> using the Emacs repository?

Yes, but it is more complicated for most users.

>     There is no legal reason for not using the Emacs repository as the
>     canonical repository for Org.  Just a practical one: doing so would
>     force us to maintain the canonical Org repository in Emacs *and* 
>     another repository for things that are useful to Org and that cannot
>     be part of Emacs.
>
> I am concerned that this practice is harmful.
> Would we want these things to be part of Emacs?
> If not, then it isn't a problem.

For some of these things, we want them in Emacs.  For others we don't
want them in Emacs.  For some we simply don't know.

For things we want to be in Org's core and then in GNU Emacs, having 
a separate contrib/ repository is a way to give everyone access to code
from authors that signed the FSF papers but whose papers are not yet
processed by the FSF.

For other things, having them in Org's repo makes sense, because it 
is a central place for anything related to Org.

-- 
 Bastien

Re: patch vs. overwrite in bzr

[Óscar Fuentes]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> On addition, when I switch branches from Emacs the relevant function is
>> advised for storing timestamps of the files of the current branch before
>> the switch and recover the timestamps of the new branch's files after
>> the switch, so no rebuild is triggered because some source file was
>> modified by the switch when the new branch already has an associated up
>> to date build.
>
> Whatfor?  git doesn't touch files that didn't change when checking out a
> different revision.

The point is to keep the timestamps of the files that did change:

1. while in branch A, build the project; build products go to build/A
   directory.

2. switch to branch B.

3. switch to branch A.

All the files that are different among those branches now have altered
timestamps, so `make' thinks the products on build/A are out of date,
when in fact they are not. The scheme I described avoids this situation.

Re: patch vs. overwrite in bzr

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> > FWIW, I like having separate branches.  At least for Emacs, and for
>> > the use case when the changes in the branch are significant (like what
>> > I had for bidi), co-located branches get in the way because switching
>> > branches needs to make a lot of changes, and requires a large build if
>> > not a full bootstrap.
>> 
>> Use out-of-source builds, with a build directory per branch...
>
> What for?  I have no problems with the above arrangement.  Joakim
> asked how others arrange their branches, and I described mine.  There
> are no problems I have that would require me to change it.

You mentioned some problems with colocated branches, and I described a
method for avoiding them. I'm not trying to convince you to change
anything.

>> unless that collides with Emacs' peculiar practice of putting build
>> products on the source tree for out-of-source builds.
>
> Nothing peculiar here: the Windows build simply doesn't support
> out-of-source builds.  But I build inside the source tree on GNU/Linux
> as well, so that's not the main reason.

The GNU/Linux build also puts products on the source tree (the .elc
files).

>> On addition, when I switch branches from Emacs the relevant function is
>> advised for storing timestamps of the files of the current branch before
>> the switch and recover the timestamps of the new branch's files after
>> the switch, so no rebuild is triggered because some source file was
>> modified by the switch when the new branch already has an associated up
>> to date build.
>
> IMO, this is a dangerous practice, because you cannot always
> second-guess what needs to be rebuilt after the switch, what with all
> the complex Makefile rules.

There is nothing dangerous about that, because you don't need to
second-guess.

> In any case, if you have branches in separate directories, you get
> that for free.

This is for people who prefer to use colocated branches.

>> vc-git solves this by displaying the current branch name on the
>> modeline. vc-bzr could do the same if colocated branches gain
>> popularity.
>
> You are assuming that I use VC to do my bzr operations.  That's false.

What you use for "bzr operations" have nothing to do with the
information displayed on the modeline, which helps hackers who use
colocated branches to know all the time which branch they are working
on.

Re: patch vs. overwrite in bzr

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 07 Apr 2012 13:56:50 +0200
> 
> >> vc-git solves this by displaying the current branch name on the
> >> modeline. vc-bzr could do the same if colocated branches gain
> >> popularity.
> >
> > You are assuming that I use VC to do my bzr operations.  That's false.
> 
> What you use for "bzr operations" have nothing to do with the
> information displayed on the modeline, which helps hackers who use
> colocated branches to know all the time which branch they are working
> on.

It helps only if one looks at the modeline when invoking the VCS
commands.

Re: patch vs. overwrite in bzr

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> > You are assuming that I use VC to do my bzr operations.  That's false.
>> 
>> What you use for "bzr operations" have nothing to do with the
>> information displayed on the modeline, which helps hackers who use
>> colocated branches to know all the time which branch they are working
>> on.
>
> It helps only if one looks at the modeline when invoking the VCS
> commands.

If the current branch name is displayed on the modeline for the files
that belong to that branch, it helps whenever you look at it, doesn't
it?

Re: patch vs. overwrite in bzr

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 07 Apr 2012 14:56:39 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> > You are assuming that I use VC to do my bzr operations.  That's false.
> >> 
> >> What you use for "bzr operations" have nothing to do with the
> >> information displayed on the modeline, which helps hackers who use
> >> colocated branches to know all the time which branch they are working
> >> on.
> >
> > It helps only if one looks at the modeline when invoking the VCS
> > commands.
> 
> If the current branch name is displayed on the modeline for the files
> that belong to that branch, it helps whenever you look at it, doesn't
> it?

What I meant was that when you invoke a VCS command, you need to be
aware which branch is the current one, or you might invoke a wrong
command.  When you invoke a VCS command, the modeline is not
necessarily in your field of view, especially if the command is not
invoked from Emacs.

Re: patch vs. overwrite in bzr

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> What I meant was that when you invoke a VCS command, you need to be
> aware which branch is the current one, or you might invoke a wrong
> command.  When you invoke a VCS command, the modeline is not
> necessarily in your field of view, especially if the command is not
> invoked from Emacs.

Well, if you are working outside of Emacs then you can't only blame your
tools for the inconvenience. Within Emacs, there is no room for
confusion when you use git colocated branches, at least with vc-git +
magit. I see no reason why working with bzr colocated branches on Emacs
couldn't be as safe as git's.

Re: patch vs. overwrite in bzr

[Richard Stallman]

    > Doesn't bzr allow them to do all the same things while
    > using the Emacs repository?

    Yes, but it is more complicated for most users.

Could we find a way to make it simpler, I wonder?
Perhaps some scripts?  Or new bzr features?

    For things we want to be in Org's core and then in GNU Emacs, having 
    a separate contrib/ repository is a way to give everyone access to code
    from authors that signed the FSF papers but whose papers are not yet
    processed by the FSF.

We are working on speeding this up.  I hope it will get done in a few
months.  I can't promise it, or give details yet.


--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: patch vs. overwrite in bzr

[Richard Stallman]

    For other things, having them in Org's repo makes sense, because it 
    is a central place for anything related to Org.

Is it possible to have two repositories that partly overlap
and partly don't?  I would think that it ought to be possible
with a DVCS.


--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: patch vs. overwrite in bzr

[Ted Zlatanov]

On Sat, 07 Apr 2012 23:25:41 -0400 Richard Stallman <rms@gnu.org> wrote: 

RS>     For other things, having them in Org's repo makes sense, because it 
RS>     is a central place for anything related to Org.

RS> Is it possible to have two repositories that partly overlap
RS> and partly don't?  I would think that it ought to be possible
RS> with a DVCS.

Yes, but it's very hard to keep them synchronized without a merge
manager, especially if you have to convert between Git and Bazaar.  For
Gnus we have Yamaoka-san who keeps us sane, doing the merges in a
semi-automatic way.  I tried to get something automatic between Gnus and
Emacs working last year and was unable to convince Bazaar to do what I
wanted, after a few days of hacking.  Perhaps it's a matter of training
and dedication I lacked; if anyone has *automated* the merge workflow
between Git and Bazaar for two large, partially overlapping and with
many files renamed, repositories, I'd love to know how it can be done.

Ted

Re: patch vs. overwrite in bzr

[Bastien]

Richard Stallman <rms@gnu.org> writes:

>     For things we want to be in Org's core and then in GNU Emacs, having 
>     a separate contrib/ repository is a way to give everyone access to code
>     from authors that signed the FSF papers but whose papers are not yet
>     processed by the FSF.
>
> We are working on speeding this up.  I hope it will get done in a few
> months.  I can't promise it, or give details yet.

Thanks!

-- 
 Bastien

Re: patch vs. overwrite in bzr [was: Next pretest, and regressions policy]

[Bastien]

Hi Eli,

Eli Zaretskii <eliz@gnu.org> writes:

> Well, I'm not sure I get all the details of your setup, so it's
> possible that I will say something silly; apologies in advance.  But
> IIUC, you could get away with less branches and less manual work.  So
> here we go:

Thanks a lot for the detailed workflow description.

I don't have the bzr-tiplog plugin installed (I don't know how to
install it), and just by reading the workflow I don't feel really
confortable in trying it...

Here is the one I used for the sync this morning:

~$ cd install/git/
~$ git clone git://git.savannah.gnu.org/emacs.git
~$ cd emacs
~$ git checkout emacs-24
~$ cd ~/install/git/org-mode/
~$ git checkout maint [the branch in sync with Emacs]
~$ cp [files from Emacs] [to files from Org]
~$ git diff > ~/emacs-sync.diff
~$ [review the diff and apply it to the maint branch]
~$ git checkout hotfix
~$ git merge maint [merge changes from Emacs]
~$ [release new Org (minor) version]
~$ git checkout maint
~$ git merge hotfix
~$ copy files from Org to Emacs (git)
~$ git diff [in Emacs git, to get the diff]
~$ review the patch and apply it to bzr emacs-24 if correct

Most of this can be automated with a few scripts, and I 
try to avoid bzr, because using Magit for git diff and other 
operations is really handy.

Best,

-- 
 Bastien

Re: patch vs. overwrite in bzr

[Jason Rumney]

Eli Zaretskii <eliz@gnu.org> writes:

> I believe this is just the general git-preference issue, which has
> nothing to do with "faster".

You can beleive what you want. At the end of a slow link, bzr is
painfully slow. A lot less painful now than it was when we first started
using it, but still more painful than git or cvs ever was.

Re: patch vs. overwrite in bzr

[Eli Zaretskii]

> From: Jason Rumney <jasonr@gnu.org>
> Cc: Bastien <bzg@gnu.org>,  emacs-devel@gnu.org,  rms@gnu.org,  monnier@iro.umontreal.ca
> Date: Mon, 16 Apr 2012 18:45:32 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I believe this is just the general git-preference issue, which has
> > nothing to do with "faster".
> 
> You can beleive what you want. At the end of a slow link, bzr is
> painfully slow. A lot less painful now than it was when we first started
> using it, but still more painful than git or cvs ever was.

I don't think anyone of the involved parties is at the end of a slow
link.

Re: patch vs. overwrite in bzr

[Richard Stallman]

    Yes, but it's very hard to keep them synchronized without a merge
    manager, especially if you have to convert between Git and Bazaar.

Maybe scripts could be designed for the specific shared repository.

And you don't have to use Git.


--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call