org changes lost

org changes lost

[Glenn Morris]

Hi,

The latest changes to org mode have overwritten several of my and
Juanma's recent small fixes (eg org-agenda.el, org.el).

Re: org changes lost

[Glenn Morris]

Glenn Morris wrote (on Sun, 23 Nov 2008 at 18:53 -0500):

> The latest changes to org mode have overwritten several of my and
> Juanma's recent small fixes (eg org-agenda.el, org.el).

Also, the org.texi license was reverted to FDL 1.2.

Re: org changes lost

[Miles Bader]

Glenn Morris <rgm@gnu.org> writes:
>> The latest changes to org mode have overwritten several of my and
>> Juanma's recent small fixes (eg org-agenda.el, org.el).
>
> Also, the org.texi license was reverted to FDL 1.2.

Hmm maybe there should be a standard text that gets sent out to new
committers, which includes things like "never, ever, simply upload the
newest version of your local sources; always merge."...

-Miles

-- 
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over.  --Ian Wolff

Re: org changes lost

[Carsten Dominik]

Sorry about this, I am going to fix it.

- Carsten

On Nov 24, 2008, at 12:53 AM, Glenn Morris wrote:

>
> Hi,
>
> The latest changes to org mode have overwritten several of my and
> Juanma's recent small fixes (eg org-agenda.el, org.el).

Re: org changes lost

[Carsten Dominik]

On Nov 24, 2008, at 4:56 AM, Miles Bader wrote:

> Glenn Morris <rgm@gnu.org> writes:
>>> The latest changes to org mode have overwritten several of my and
>>> Juanma's recent small fixes (eg org-agenda.el, org.el).
>>
>> Also, the org.texi license was reverted to FDL 1.2.
>
> Hmm maybe there should be a standard text that gets sent out to new
> committers, which includes things like "never, ever, simply upload the
> newest version of your local sources; always merge."...

My skills in version control my not be sufficient to do this, jumping
between different version control worlds.
So I work by applying changed in Emacs to my local copy and reserve the
right to undo changes made in Emacs (not that this has been necessary
recently).  Usually this works OK, occasionally, like yesterday,
I miss something.

Despite the FSF holding the copyright for these files, the "master"
version is still the one in my own repository.

For me the biggest improvement would be to get an email copy
of all changes to files where I am the maintainer, not buried
in the general commits digest (where I do overlook things),
but a personalized one. I am sure that such emails could be
generated automatically, but I don't know how.

- Carsten

Re: org changes lost

[Chong Yidong]

Carsten Dominik <carsten.dominik@gmail.com> writes:

>> Hmm maybe there should be a standard text that gets sent out to new
>> committers, which includes things like "never, ever, simply upload the
>> newest version of your local sources; always merge."...
>
> My skills in version control my not be sufficient to do this, jumping
> between different version control worlds.  So I work by applying
> changed in Emacs to my local copy and reserve the right to undo
> changes made in Emacs (not that this has been necessary recently).
> Usually this works OK, occasionally, like yesterday, I miss something.

Why don't you just use `cvs update' to merge in changes?

Re: org changes lost

[Glenn Morris]

Carsten Dominik wrote:

> For me the biggest improvement would be to get an email copy
> of all changes to files where I am the maintainer, not buried
> in the general commits digest (where I do overlook things),
> but a personalized one. I am sure that such emails could be
> generated automatically, but I don't know how.


Thanks for fixing it. You could do some filtering on the general diff
mailing list, on anything with org in the subject. Eg Gnus scoring, or
procmail forwarding to a separate folder.

Re: org changes lost

[Reiner Steib]

On Mon, Nov 24 2008, Carsten Dominik wrote:

> For me the biggest improvement would be to get an email copy
> of all changes to files where I am the maintainer, not buried
> in the general commits digest (where I do overlook things),
> but a personalized one. I am sure that such emails could be
> generated automatically, but I don't know how.

You could subscribe emacs-diffs (without the digest option) and drop
everything where the Subject doesn't match "emacs/doc/misc org.texi"
or "emacs/lisp/org".

MH-E commit mails (on the Emacs repository) are redirected to the MH-E
devel list, so it's also possible to do this in CVS directly.

For tracking changes in Gnus, I simply use score file entries to
highlight commits touching Gnus related files.

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

Re: org changes lost

[Bastien]

Glenn Morris <rgm@gnu.org> writes:

> Carsten Dominik wrote:
>
>> For me the biggest improvement would be to get an email copy
>> of all changes to files where I am the maintainer, not buried
>> in the general commits digest (where I do overlook things),
>> but a personalized one. I am sure that such emails could be
>> generated automatically, but I don't know how.
>
> Thanks for fixing it. You could do some filtering on the general diff
> mailing list, on anything with org in the subject. Eg Gnus scoring, or
> procmail forwarding to a separate folder.

I usually do this filtering myself and forward commits to Carsten (or
apply them myself to the Org's repository) I was pretty busy the last
month and forgot to do this, sorry.

-- 
 Bastien

Re: org changes lost

[Stefan Monnier]

> My skills in version control my not be sufficient to do this, jumping
> between different version control worlds.

You just need to reflect the branch of one into a branch of the other
(one-way only), so it's not that difficult.  E.g. you can commit (via
naive overwrite&commit) your externally-maintaned code into a special
branch in the CVS, and then use cvs to merge the changes from that
branch into the trunk.

Or you can do it the other way around and take a copy of Emacs's trunk
every once in a while, commit it onto a special branch in your main
VCS (e.g. Bzr or Git), and then merge that branch into your main branch.

The safer thing to do (when working between VCS or without VCS) is to
never copy files, but only ever take diffs and apply them.  It's not
like taking diffs is safer but it forces you to think "diff between what
and what", so it makes it more likely that you'll do the right thing.

> So I work by applying changed in Emacs to my local copy and reserve the
> right to undo changes made in Emacs (not that this has been necessary
> recently).  Usually this works OK, occasionally, like yesterday,
> I miss something.

To avoid this, try to do a "diff since last sync" and apply that to
Emacs's repository.  This may result in conflicts, but only if there are
concurrent changes that you need to pay attention to.

> For me the biggest improvement would be to get an email copy
> of all changes to files where I am the maintainer, not buried
> in the general commits digest (where I do overlook things),
> but a personalized one. I am sure that such emails could be
> generated automatically, but I don't know how.

That would be good indeed.  Maybe someone could setup such a service:
register to emacs-diffs, and then use a table that maps file names to
maintainers's email addresses to figure out to whom to send the email.
The table can be rebuilt daily by looking at the Elisp files's
"Maintainer:" or "Author:" line and the admin/MAINTAINERS (which is
a bit out-of-date, AFAIK).  This data tends to be out-of-date, tho, so
while this doesn't mean it's a bad idea, it means your email filter
should be careful to handle such things gracefully (whatever that
means, my guess is that it'll just work without having to do anything
special, other than add a little blurb to the email to explain how to
"unsubscribe").


        Stefan

Re: org changes lost

[Chong Yidong]

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

>> For me the biggest improvement would be to get an email copy
>> of all changes to files where I am the maintainer, not buried
>> in the general commits digest (where I do overlook things),
>> but a personalized one. I am sure that such emails could be
>> generated automatically, but I don't know how.
>
> That would be good indeed.  Maybe someone could setup such a service:
> register to emacs-diffs, and then use a table that maps file names to
> maintainers's email addresses to figure out to whom to send the email.

Probably easier to do on the client side: subscribe to emacs-diffs and
use gnus splitting rules to move only mails about files you are
interested in to an folder that you read (the names of the changed files
are in the Subject lines, so this is easy).

Re: org changes lost

[Yavor Doganov]

Stefan Monnier wrote:
> 
> > For me the biggest improvement would be to get an email copy
> > of all changes to files where I am the maintainer, not buried
> > in the general commits digest
> 
> That would be good indeed.  

As Reiner already mentioned, it is trivial to setup (on the Savannah
side) notifications to go to both emacs-diffs and another address for
specific directories, as is done for MH-E.

An alternative is to use Mailman's "topics" feature but as the Subject
of the messages is truncated, that is not very reliable.

Re: org changes lost

[Bastien]

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

>> For me the biggest improvement would be to get an email copy
>> of all changes to files where I am the maintainer, not buried
>> in the general commits digest (where I do overlook things),
>> but a personalized one. I am sure that such emails could be
>> generated automatically, but I don't know how.
>
> That would be good indeed.  Maybe someone could setup such a service:
> register to emacs-diffs, and then use a table that maps file names to
> maintainers's email addresses to figure out to whom to send the email.

I've set up such a system.

Carsten, if you're okay with this, I can automatically forward
org-related emails from [emacs-commit] and [emacs-diffs] to you.

I've not done this for all Emacs projects so far, partly because the
MAINTAINERS file might not be 100% accurate, partly because I want to
check the system behaves correctly, and partly because I'm lazy.

If any maintainer needs such a forward, let me know.

-- 
 Bastien

Re: org changes lost

[Bastien]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> MH-E commit mails (on the Emacs repository) are redirected to the MH-E
> devel list, so it's also possible to do this in CVS directly.

How do you do this?

-- 
 Bastien

Re: org changes lost

[Carsten Dominik]

On Nov 24, 2008, at 5:32 PM, Chong Yidong wrote:

> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
>>> Hmm maybe there should be a standard text that gets sent out to new
>>> committers, which includes things like "never, ever, simply upload  
>>> the
>>> newest version of your local sources; always merge."...
>>
>> My skills in version control my not be sufficient to do this, jumping
>> between different version control worlds.  So I work by applying
>> changed in Emacs to my local copy and reserve the right to undo
>> changes made in Emacs (not that this has been necessary recently).
>> Usually this works OK, occasionally, like yesterday, I miss  
>> something.
>
> Why don't you just use `cvs update' to merge in changes?


How would that work?  I copy my new files into the lisp/org directory
and then call cvs update to merge any changes from the Emacs crowd?
Hmm, this means the I cannot call cvs update in between, just to
get the changes in other files.

OK, thinking about it.

- Carsten

Re: org changes lost

[Carsten Dominik]

On Nov 24, 2008, at 7:23 PM, Reiner Steib wrote:

> On Mon, Nov 24 2008, Carsten Dominik wrote:
>
>> For me the biggest improvement would be to get an email copy
>> of all changes to files where I am the maintainer, not buried
>> in the general commits digest (where I do overlook things),
>> but a personalized one. I am sure that such emails could be
>> generated automatically, but I don't know how.
>
> You could subscribe emacs-diffs (without the digest option) and drop
> everything where the Subject doesn't match "emacs/doc/misc org.texi"
> or "emacs/lisp/org".

This sounds feasible as well, thanks.

- Carsten

Re: org changes lost

[Carsten Dominik]

Hi Bastien,

I would appreciate this service, thank you very much.

- Carsten

On Nov 25, 2008, at 10:03 AM, Bastien wrote:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> For me the biggest improvement would be to get an email copy
>>> of all changes to files where I am the maintainer, not buried
>>> in the general commits digest (where I do overlook things),
>>> but a personalized one. I am sure that such emails could be
>>> generated automatically, but I don't know how.
>>
>> That would be good indeed.  Maybe someone could setup such a service:
>> register to emacs-diffs, and then use a table that maps file names to
>> maintainers's email addresses to figure out to whom to send the  
>> email.
>
> I've set up such a system.
>
> Carsten, if you're okay with this, I can automatically forward
> org-related emails from [emacs-commit] and [emacs-diffs] to you.
>
> I've not done this for all Emacs projects so far, partly because the
> MAINTAINERS file might not be 100% accurate, partly because I want to
> check the system behaves correctly, and partly because I'm lazy.
>
> If any maintainer needs such a forward, let me know.
>
> -- 
> Bastien

Re: org changes lost

[Carsten Dominik]

On Nov 25, 2008, at 3:50 AM, Stefan Monnier wrote:

>> My skills in version control my not be sufficient to do this, jumping
>> between different version control worlds.
>
> You just need to reflect the branch of one into a branch of the other
> (one-way only), so it's not that difficult.  E.g. you can commit (via
> naive overwrite&commit) your externally-maintaned code into a special
> branch in the CVS, and then use cvs to merge the changes from that
> branch into the trunk.
>
> Or you can do it the other way around and take a copy of Emacs's trunk
> every once in a while, commit it onto a special branch in your main
> VCS (e.g. Bzr or Git), and then merge that branch into your main  
> branch.
>
> The safer thing to do (when working between VCS or without VCS) is to
> never copy files, but only ever take diffs and apply them.  It's not
> like taking diffs is safer but it forces you to think "diff between  
> what
> and what", so it makes it more likely that you'll do the right thing.

Yes, this sounds like the sane thing todo.  However, there are  
complications for this, such as the fact that the directory structure  
in my own repo is slightly different, and that I need to change the  
commit dates in the ChangeLog file when updating the files in Emacs,  
so at least for me tere is always some hand fiddling involved.

>
>
>> So I work by applying changed in Emacs to my local copy and reserve  
>> the
>> right to undo changes made in Emacs (not that this has been necessary
>> recently).  Usually this works OK, occasionally, like yesterday,
>> I miss something.
>
> To avoid this, try to do a "diff since last sync" and apply that to
> Emacs's repository.  This may result in conflicts, but only if there  
> are
> concurrent changes that you need to pay attention to.

Yes.  I do follow Emacs development through a git mirror, and since
yesterday I do have a local tag that is called last-sync-with-org-repo.
At lease as a double-checking mechanism this will be effective, I hope.

Thanks

- Carsten

Re: org changes lost

[Stefan Monnier]

>>> For me the biggest improvement would be to get an email copy
>>> of all changes to files where I am the maintainer, not buried
>>> in the general commits digest (where I do overlook things),
>>> but a personalized one. I am sure that such emails could be
>>> generated automatically, but I don't know how.
>> 
>> That would be good indeed.  Maybe someone could setup such a service:
>> register to emacs-diffs, and then use a table that maps file names to
>> maintainers's email addresses to figure out to whom to send the email.

> Probably easier to do on the client side: subscribe to emacs-diffs and
> use gnus splitting rules to move only mails about files you are
> interested in to an folder that you read (the names of the changed files
> are in the Subject lines, so this is easy).

That requires every externally managed author to setup such rules.
What I suggest is to it once and for all.
It will also have the advantage of sending to email even to those who
otherwise wouldn't think of subsribing to emacs-diffs.


        Stefan

Re: org changes lost

[Stefan Monnier]

>> > For me the biggest improvement would be to get an email copy
>> > of all changes to files where I am the maintainer, not buried
>> > in the general commits digest
>> That would be good indeed.  
> As Reiner already mentioned, it is trivial to setup (on the Savannah
> side) notifications to go to both emacs-diffs and another address for
> specific directories, as is done for MH-E.

Per-directory is not fine grained enough.  Also I want the destination
address to be automatically setup, based on the "Maintainer:" field
contained in the files.


        Stefan

Re: org changes lost

[Stefan Monnier]

> I've set up such a system.

Good.

> Carsten, if you're okay with this, I can automatically forward
> org-related emails from [emacs-commit] and [emacs-diffs] to you.

IIUC emacs-diffs should now be a superset of emacs-commit, so
emacs-commit should not be necessary.

> I've not done this for all Emacs projects so far, partly because the
> MAINTAINERS file might not be 100% accurate,

It's OK if it's not accurate: that will hopefully prompt people to make
it more accurate.  But the main source of such info is in the header of
each Elisp file (look for ";; Author:" or ";; Maintainer: " in the
section between the first line and the ";;; Commentary").  Look at
lisp-mnt.el for some utility functions that can find that field for you.

> partly because I want to check the system behaves correctly, and

Good.

> partly because I'm lazy.

Good.

> If any maintainer needs such a forward, let me know.

Please do it unconditionally.  People should explicitly "opt out" rather
than explicitly "opt in".


        Stefan

Re: org changes lost

[Bastien]

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

> IIUC emacs-diffs should now be a superset of emacs-commit, so
> emacs-commit should not be necessary.

Okay, I'm just forwarding emacs-diffs.

>> I've not done this for all Emacs projects so far, partly because the
>> MAINTAINERS file might not be 100% accurate,
>
> It's OK if it's not accurate: that will hopefully prompt people to make
> it more accurate.  But the main source of such info is in the header of
> each Elisp file (look for ";; Author:" or ";; Maintainer: " in the
> section between the first line and the ";;; Commentary").  Look at
> lisp-mnt.el for some utility functions that can find that field for you.

I understand the setup you have in mind, but I don't I don't feel
comfortable in automatically forwarding emails to people I don't know.

I suggest we first send an email to all the maintainers asking them if
they want such a reminder for themselves.  Maybe most of them already
filter through [emacs-diffs] and don't need additional forwards.  And
maybe encouraging *every* Emacs developer to only stay focused on his
own piece of code will is not a good thing to do.

Thoughts?

-- 
 Bastien

Re: org changes lost

[Reiner Steib]

On Tue, Nov 25 2008, Bastien wrote:

> Reiner Steib <reinersteib+gmane@imap.cc> writes:
>
>> MH-E commit mails (on the Emacs repository) are redirected to the MH-E
>> devel list, so it's also possible to do this in CVS directly.
>
> How do you do this?

I just heard about it, so I don't know the details[1].  The savannah
admins or Bill Wohler (MH-E maintainer) should know.

[1] Maybe via (info "(cvs)Getting Notified")?

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

Re: org changes lost

[Michael Olson]

Carsten Dominik <carsten.dominik@gmail.com> writes:

> Yes.  I do follow Emacs development through a git mirror, and since
> yesterday I do have a local tag that is called last-sync-with-org-repo.
> At lease as a double-checking mechanism this will be effective, I hope.

I'd recommend using a dedicated "emacs23" branch instead of a tag.  Sync
just that branch with Emacs CVS.  After syncing from Emacs, cherry-pick
the changes you want for master (I use git add -p to group the changes
into semi-atomic commits first before committing them).

In order to sync to Emacs, sync emacs23 first, merge master to emacs23,
*then* overwrite files in Emacs CVS using what's in the emacs23 branch
(or commit first to a git repo of Emacs, then use git-cvsexportcommit to
apply the patch to CVS).

-- 
|       Michael Olson  |  FSF Associate Member #652     |
| http://mwolson.org/  |  Hobbies: Lisp, HCoop          |
| Projects: Emacs, Muse, ERC, EMMS, ErBot, DVC, Planner |
`-------------------------------------------------------'