From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Reitter Newsgroups: gmane.emacs.devel Subject: Re: Emacs-24.4's release Date: Thu, 5 Feb 2015 10:06:23 -0500 Message-ID: References: <20141014215424.GA17044@thyrsus.com> <5826765D-B430-4CCF-BA9D-B38DE1BD04C4@gmail.com> <20141014224926.GA18117@thyrsus.com> <8EA1E52E-C298-4134-B60E-973412F90FA3@gmail.com> <54D3848A.3050709@swipnet.se> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1423148797 6087 80.91.229.3 (5 Feb 2015 15:06:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 5 Feb 2015 15:06:37 +0000 (UTC) Cc: esr@thyrsus.com, "emacs-devel@gnu.org developers" To: "Jan D." Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 05 16:06:36 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YJO0p-0006Ew-08 for ged-emacs-devel@m.gmane.org; Thu, 05 Feb 2015 16:06:35 +0100 Original-Received: from localhost ([::1]:42567 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJO0o-0004my-EJ for ged-emacs-devel@m.gmane.org; Thu, 05 Feb 2015 10:06:34 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39237) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJO0i-0004mL-TL for emacs-devel@gnu.org; Thu, 05 Feb 2015 10:06:30 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YJO0f-0001W6-Mp for emacs-devel@gnu.org; Thu, 05 Feb 2015 10:06:28 -0500 Original-Received: from mail-qc0-x22a.google.com ([2607:f8b0:400d:c01::22a]:44642) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJO0f-0001Vv-Gx for emacs-devel@gnu.org; Thu, 05 Feb 2015 10:06:25 -0500 Original-Received: by mail-qc0-f170.google.com with SMTP id p6so6767714qcv.1 for ; Thu, 05 Feb 2015 07:06:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aID1eCR9rBeOcZI8eyVZwF4rFNdq8Q5g9Tjy0hBI3lo=; b=wrwpmhr5qG7gKeB0f7e7SvV00JKX0yNdFppsVfHS+3LCMfqRViIp5i1EcWyePT/utV JCgX9x6KQpWWYyQ4T5tIt1t08+blWx8AEmXZm4QsgO5VmENbV0I7LGA46SwrYsC+4DVn Gbhm5e06R8C+cKDXl83CDfKRVp1SK4/9jZhUNqOETluPhiLvmUHtm1q0dl7wuz53g0SS FCKoiDsD4D9Q8i11TyBm+aAUjUq7LSj1lo830HTcD7tNJebgQF0+QYO4oHR4jX6Pjt/6 pWz6YG8q2gJiWy0qDwmeiya0wTdtF7o0oxLUq2fWsT785g3G8e71/0dKjGFz+FPTGyDl OVMg== X-Received: by 10.140.81.74 with SMTP id e68mr8418031qgd.41.1423148785221; Thu, 05 Feb 2015 07:06:25 -0800 (PST) Original-Received: from [130.203.154.138] ([130.203.154.138]) by mx.google.com with ESMTPSA id h34sm5155010qge.6.2015.02.05.07.06.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Feb 2015 07:06:24 -0800 (PST) In-Reply-To: <54D3848A.3050709@swipnet.se> X-Mailer: Apple Mail (2.2070.6) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400d:c01::22a X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:182451 Archived-At: Hi Jan, I=E2=80=99m not sure why you=E2=80=99re asking, so there are two = answers: As for the repository, we don=E2=80=99t actually have a branch in the = GNU Emacs repository and don=E2=80=99t need one - and if that=E2=80=99s = what you=E2=80=99re asking - I=E2=80=99m 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: =20 Aquamacs is at liberty to incorporate any GPL=E2=80=99ed 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=E2=80=99s 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. wrote: >=20 > 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? >=20 > Jan D. >=20 > David Reitter skrev den 2015-02-05 01:31: >> Hi Eric, >>=20 >> I=E2=80=99d 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. >>=20 >> - David >>=20 >>=20 >>=20 >>=20 >>> On Oct 14, 2014, at 6:49 PM, Eric S. Raymond = wrote: >>>=20 >>> David Reitter : >>>> On Oct 14, 2014, at 5:54 PM, Eric S. Raymond = wrote: >>>>=20 >>>>> I could construct one, but this is not a request that has come up >>>>> before. It would require a significant amount of new work. >>>>=20 >>>> Well, the thing is, I don=E2=80=99t 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. >>>=20 >>> 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. >>>=20 >>>> I might cut off all history prior to 2005, =E2=80=9Cflatten=E2=80=9D = 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. >>>>=20 >>>> This will destroy a lot of history on my end, which is lamentable. >>>=20 >>> Let's try to avoid that. >>>=20 >>> 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. >>>=20 >>> That is doable. Here's how I would approach it: >>>=20 >>> 1. Write a script that use git log to generate a file of lines >>> pairing each hash with its version stamp. >>>=20 >>> 2. Run it on the old git repo. Then run it on your repo. >>>=20 >>> 3. Write another little script to join these reports, using >>> version-stamp as a primary key. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>> -- >>> Eric S. = Raymond >>=20 >=20