Re: Emacs-24.4's release

[David Reitter <david.reitter@gmail.com>]

Hi Jan,

I’m not sure why you’re asking, so there are two answers:

As for the repository, we don’t actually have a branch in the GNU Emacs repository and don’t need one - and if that’s what you’re asking - I’m not planning for this to happen.

But of course I merge regularly from the Emacs branches, and the big rebase that Eric did prevents me from continuing unless we transplant or discard 10 years of Aquamacs history somehow.

As for using code from Aquamacs and copyright:
 
Aquamacs is at liberty to incorporate any GPL’ed and license-compatible code into its codebase.  Contributors retain their copyright and license it under the GPL as appropriate.  They have not signed GNU papers.

I myself have signed papers.  If you want to use any of my code, that’s fine by me of course.  In fact, I would like to see more of that.

- David


> On Feb 5, 2015, at 9:56 AM, Jan D. <jan.h.d@swipnet.se> wrote:
> 
> Hi.
> A while back there was some copyright discussion when I took some code from Aquamacs, so I don't do that anymore.  Has this been resolved, i.e. has all contributors to Aquamacs signed papers?
> 
> 	Jan D.
> 
> David Reitter skrev den 2015-02-05 01:31:
>> Hi Eric,
>> 
>> I’d like to pick up where we left off last year, now that the dust has settled with the Emacs transition.
>> Can we discuss how to get Aquamacs transitioned to the new repository?
>> More info by e-mail - I sent you two e-mails earlier in the week.
>> 
>> - David
>> 
>> 
>> 
>> 
>>> On Oct 14, 2014, at 6:49 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
>>> 
>>> David Reitter <david.reitter@gmail.com>:
>>>> On Oct 14, 2014, at 5:54 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
>>>> 
>>>>> I could construct one, but this is not a request that has come up
>>>>> before.  It would require a significant amount of new work.
>>>> 
>>>> Well, the thing is, I don’t know how to convert my downstream
>>>> project, which has 10 years worth of its own development and regular
>>>> merges against two version of the git mirrors, the later one quite
>>>> official and GNU/FSF sanctioned.
>>> 
>>> Ah, right, you're the Aquamacs guy.  I haven't given up on heelping you
>>> accomplish what you want, but I didn't see a lot of point in pursuing
>>> it util the main conversion is done.
>>> 
>>>> I might cut off all history prior to 2005, “flatten” the merges somehow (so that they lose their Emacs-side parent), and then re-connect to the new Emacs repository with a merge right at the point where you do the conversion.
>>>> 
>>>> This will destroy a lot of history on my end, which is lamentable.
>>> 
>>> Let's try to avoid that.
>>> 
>>> What you need, then, is a mapping from the hashes corresponding to your
>>> merge points to the merge points in the conversion?  To, I take it, be
>>> used later when we try building a repo based on the new official git
>>> that includes your work.
>>> 
>>> That is doable. Here's how I would approach it:
>>> 
>>> 1. Write a script that use git log to generate a file of lines
>>> pairing each hash with its version stamp.
>>> 
>>> 2. Run it on the old git repo.  Then run it on your repo.
>>> 
>>> 3. Write another little script to join these reports, using
>>> version-stamp as a primary key.
>>> 
>>> 4. You then need to give me a list of your merge links from the
>>> old repo - that is, all the pairs of parent/child hash pairs that
>>> represent merges into your repository.
>>> 
>>> 5. Then we sanity-check.  If either the set of parent hashes or the
>>> set of child hashes is paired with any duplicate version stamps (very
>>> unlikely but theoretically possible) life gets complicated.  Let's
>>> assume that doesn't happen.
>>> 
>>> 6. If life has not become complicated, we now have an unambiguous
>>> representation of the cross-repository links as both hash pairs
>>> and version-stamp pairs.
>>> 
>>> 7. Now (he said, taking a deep breath) we write another script.
>>> It walks through your repository, emitting Aquamacs commits as
>>> git-import-stream objects in which some merge links (those that point to
>>> parents outside your branch) are version stamps rather than marks.
>>> 
>>> 8. reposurgeon has a variant graft operation that can merge this
>>> stream into a copy of the new git repo. I wrote this specifically
>>> for your use case.
>>> --
>>> 		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
>> 
>