From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Artur Malabarba Newsgroups: gmane.emacs.devel Subject: Re: Requesting review before pushing patch to ELPA Date: Wed, 4 Feb 2015 11:16:57 +0000 Message-ID: References: Reply-To: bruce.connor.am@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b41890b55695a050e41530f X-Trace: ger.gmane.org 1423048639 15809 80.91.229.3 (4 Feb 2015 11:17:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 4 Feb 2015 11:17:19 +0000 (UTC) Cc: emacs-devel To: Jackson Hamilton Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 04 12:17:19 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 1YIxxO-00038l-Mk for ged-emacs-devel@m.gmane.org; Wed, 04 Feb 2015 12:17:18 +0100 Original-Received: from localhost ([::1]:35639 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIxxO-0005xV-2e for ged-emacs-devel@m.gmane.org; Wed, 04 Feb 2015 06:17:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49748) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIxx5-0005xI-Lk for emacs-devel@gnu.org; Wed, 04 Feb 2015 06:17:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YIxx3-0004Vs-UY for emacs-devel@gnu.org; Wed, 04 Feb 2015 06:16:59 -0500 Original-Received: from mail-ob0-x229.google.com ([2607:f8b0:4003:c01::229]:37031) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIxx3-0004Vm-Ms for emacs-devel@gnu.org; Wed, 04 Feb 2015 06:16:57 -0500 Original-Received: by mail-ob0-f169.google.com with SMTP id wp4so822824obc.0 for ; Wed, 04 Feb 2015 03:16:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=O4HUUTBR41q4M54KDfyxYAvmm+WZ7GRcoQE9XYSY5k8=; b=L5EHyhCoPPSEWwaDvAMTfSg2cdz7bXUfWygbrmoUBYRRjgJ+T0ECh4Zqb1CEaMa3yM v9N86+UES/LL668jNNtgiwBlvjXcXzNsFfSw8ee0A/ODjs6uaMCdgn00PEuwTn9q1XTM fMdtrsJjjVo3rZ2tEjJbhkvlZg4DhHsk8SQqQBlW77gD685v58Auj0gpUKnIJ4DrwdXA xKpIdgiFM3OkQBtNuGU+oMs2DPT6lgRNoko5R5yxV+Zr0dcu/Dza3li+wWM/IYcI6IQ8 lJwjEu09swnZoKNHhpoTWv3ze6o5s3KA7U4ETUk4h1VhTprW4weR7U7byZlqxEMJP7BL rxcg== X-Received: by 10.60.135.3 with SMTP id po3mr18505182oeb.58.1423048617320; Wed, 04 Feb 2015 03:16:57 -0800 (PST) Original-Received: by 10.76.125.1 with HTTP; Wed, 4 Feb 2015 03:16:57 -0800 (PST) In-Reply-To: X-Google-Sender-Auth: -MhR5OiVsHyPKsUzthk6Rob5pZ4 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4003:c01::229 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:182365 Archived-At: --047d7b41890b55695a050e41530f Content-Type: text/plain; charset=UTF-8 The formatting of that e-mail was all off. Let me try again with rich text: ------------------------------ You have two options. In both cases, you'll have a separate elpa branch on your repo. Whenever you do your git subtree merging into the GNU Elpa repository, use your repo's elpa branch as the remote (instead of master). You can: 1. Create an elpa branch in your repo, child of the master branch. 2. Delete from the elpa branch everything but the package source files. 3. Whenever you update master, merge that into elpa. This has two small disadvantages. - Every time you edit a test file you'll get a merge conflict when you try to merge master into elpa. - Even though you deleted the files from HEAD, they will still exist in the history of your repo (and therefore, in the history of the GNU Elpa repo). You can also: 1. Create an *orphan* elpa branch, and manually place in there *only* the files you're ok with. 2. Delete and recreate the master branch. 3. Merge elpa into master, then manually add to master all of the files you didn't want on elpa. 4. Do your development on the elpa branch, and merge that into master. This has the advantage that the unwanted files will be wiped from history, so the GNU Elpa repo will never know about them. It has the obvious disadvantage that it will completely reset your repo's history. 2015-02-04 9:15 GMT-02:00 Artur Malabarba : > You have two options. In both cases, you'll have a separate elpa > branch on your repo. Whenever you do your git subtree merging into the > GNU Elpa repository, use your repo's elpa branch as the remote > (instead of master). > > You can: > > Create an elpa branch in your repo, child of the master branch. > Delete from the elpa branch everything but the package source files. > Whenever you update master, merge that into elpa. > > This has two small disadvantages. - Every time you edit a test file > you'll get a merge conflict when you try to merge master into elpa. - > Even though you deleted the files from HEAD, they will still exist in > the history of your repo (and therefore, in the history of the GNU > Elpa repo). > > You can also (this is the one I used): > > Create an orphan elpa branch, and manually place in there only the > files you're ok with. > Delete and recreate the master branch. > Merge elpa into master, then manually add to master all of the files > you didn't want on elpa. > Do your development on the elpa branch, and merge that into master. > > This has the advantage that the unwanted files will be wiped from > history, so the GNU Elpa repo will never know about them. It has the > obvious disadvantage that it will completely reset your repo's > history. > > > Cheers > > 2015-02-04 7:24 GMT-02:00 Jackson Hamilton >: > > Hi Artur, I am interested in the "git details". Please elaborate. > > > > On Tue, Feb 3, 2015 at 4:13 AM, Artur Malabarba < > bruce.connor.am@gmail.com> > > wrote: > >> > >> If that package is only used for testing, you can also just not merge > >> it into elpa and do your testing elsewhere (e.g. Travis+github). > >> That's what I did with Names, because the tests involved a lot of > >> packages from other people with a ton of changes made by me. I'm not > >> saying I couldn't put those inside the Elpa/package/ directory, but it > >> was easier this way than to worry about copyrights. > >> > >> I can go into the `git' details necessary for this if you'd like. > >> > >> 2015-02-03 5:57 GMT+00:00 Jackson Hamilton > >> : > >> > On the "Copyright (C) 2014 Johan Andersson", are you suggesting I > change > >> > the > >> > copyright notice in ert-async.el myself, or that I should contact the > >> > author > >> > and tell him to change it? > >> > > >> > In either case that seems inappropriate. > >> > > >> > context-coloring/languages/javascript/libraries/ also includes 3 > >> > JavaScript > >> > libraries with their own copyright notices. These appear to be > licensed > >> > under the FreeBSD license. Should they be handled specially? > >> > > >> > Regards, > >> > Jackson > >> > > >> > On Mon, Feb 2, 2015 at 9:58 AM, Stefan Monnier > >> > > >> > wrote: > >> >> > >> >> > which included 247 commits. I am not sure if these should be > >> >> > squashed, > >> >> > but > >> >> > based on the commit log it seems like this subtree approach is how > >> >> > other > >> >> > people are managing their externally-maintained packages, so I > assume > >> >> > it > >> >> > is > >> >> > okay to add the whole history. > >> >> > >> >> Indeed, it's OK to keep the history. > >> >> > >> >> > On top of that, I added 2 patches so that I could test ELPA > locally. > >> >> > I > >> >> > was > >> >> > able to install my package via a "local-elpa" as described in the > >> >> > README. > >> >> > The patches for that are attached in this email. > >> >> > >> >> I think the hydra-test.el has been fixed by someone else in the > >> >> mean time. As for your change: > >> >> > >> >> > +./context-coloring/libraries/ert-async.el:;; Copyright (C) 2014 > >> >> > Johan > >> >> > Andersson > >> >> > >> >> I think this change is incorrect. IIUC this is > johan.rejeep@gmail.com > >> >> we're talking bout, and he signed the copyright assignment forms, so > >> >> the line in ert-async.el should say "Copyright (C) 2014 Free Software > >> >> Foundation, Inc" (at which point you won't need any change to > >> >> copyright_exceptions). > >> >> > >> >> > >> >> Stefan > >> > > >> > > > > > > --047d7b41890b55695a050e41530f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

The formatting of that e-mail was all off. Let me try a= gain with rich text:

You have two options. In both cases, you'll have a separate el= pa branch on your repo. Whenever you do your git subtree merging = into the GNU Elpa repository, use your repo's elpa branch as th= e remote (instead of master).

You can:

  1. Create an elpa branch in your repo, child of the mas= ter branch.
  2. Delete from the elpa branch everything but the package sou= rce files.
  3. Whenever you update master, merge that into elpa.

This has two small disadvantages.

  • Every time you edit a test file you'll get a merge conflict when yo= u try to merge master into elpa.
  • Even though you deleted the files from HEAD, they will sti= ll exist in the history of your repo (and therefore, in the history of the = GNU Elpa repo).

You can also:

  1. Create an orphan elpa branch, and manuall= y place in there only the files you're ok with.
  2. Delete and recreate the master branch.
  3. Merge elpa into master, then manually add to = master all of the files you didn't want on elpa.
  4. Do your development on the elpa branch, and merge that int= o master.

This has the advantage that the unwanted files will be wiped from history, so the GNU Elpa repo will never know about them. It has the obvious disadvantage that it will completely reset your repo's history.


2015-02-04 = 9:15 GMT-02:00 Artur Malabarba <bruce.connor.am@gmail.com><= /span>:
You have two options. In both cas= es, you'll have a separate elpa
branch on your repo. Whenever you do your git subtree merging into the
GNU Elpa repository, use your repo's elpa branch as the remote
(instead of master).

You can:

Create an elpa branch in your repo, child of the master branch.
Delete from the elpa branch everything but the package source files.
Whenever you update master, merge that into elpa.

This has two small disadvantages. - Every time you edit a test file
you'll get a merge conflict when you try to merge master into elpa. - Even though you deleted the files from HEAD, they will still exist in
the history of your repo (and therefore, in the history of the GNU
Elpa repo).

You can also (this is the one I used):

Create an orphan elpa branch, and manually place in there only the
files you're ok with.
Delete and recreate the master branch.
Merge elpa into master, then manually add to master all of the files
you didn't want on elpa.
Do your development on the elpa branch, and merge that into master.

This has the advantage that the unwanted files will be wiped from
history, so the GNU Elpa repo will never know about them. It has the
obvious disadvantage that it will completely reset your repo's
history.


Cheers

2015-02-04 7:24 GMT-02:00 Jackson Hamilton <jackson@jacksonrayhamilton.com>:
> Hi Artur, I am interested in t= he "git details". Please elaborate.
>
> On Tue, Feb 3, 2015 at 4:13 AM, Artur Malabarba <bruce.connor.am@gmail.com>
> wrote:
>>
>> If that package is only used for testing, you can also just not me= rge
>> it into elpa and do your testing elsewhere (e.g. Travis+github). >> That's what I did with Names, because the tests involved a lot= of
>> packages from other people with a ton of changes made by me. I'= ;m not
>> saying I couldn't put those inside the Elpa/package/ directory= , but it
>> was easier this way than to worry about copyrights.
>>
>> I can go into the `git' details necessary for this if you'= d like.
>>
>> 2015-02-03 5:57 GMT+00:00 Jackson Hamilton
>> <jackson@jack= sonrayhamilton.com>:
>> > On the "Copyright (C) 2014 Johan Andersson", are yo= u suggesting I change
>> > the
>> > copyright notice in ert-async.el myself, or that I should con= tact the
>> > author
>> > and tell him to change it?
>> >
>> > In either case that seems inappropriate.
>> >
>> > context-coloring/languages/javascript/libraries/ also include= s 3
>> > JavaScript
>> > libraries with their own copyright notices. These appear to b= e licensed
>> > under the FreeBSD license. Should they be handled specially?<= br> >> >
>> > Regards,
>> > Jackson
>> >
>> > On Mon, Feb 2, 2015 at 9:58 AM, Stefan Monnier
>> > <monnier@iro.u= montreal.ca>
>> > wrote:
>> >>
>> >> > which included 247 commits. I am not sure if these s= hould be
>> >> > squashed,
>> >> > but
>> >> > based on the commit log it seems like this subtree a= pproach is how
>> >> > other
>> >> > people are managing their externally-maintained pack= ages, so I assume
>> >> > it
>> >> > is
>> >> > okay to add the whole history.
>> >>
>> >> Indeed, it's OK to keep the history.
>> >>
>> >> > On top of that, I added 2 patches so that I could te= st ELPA locally.
>> >> > I
>> >> > was
>> >> > able to install my package via a "local-elpa&qu= ot; as described in the
>> >> > README.
>> >> > The patches for that are attached in this email.
>> >>
>> >> I think the hydra-test.el has been fixed by someone else = in the
>> >> mean time.=C2=A0 As for your change:
>> >>
>> >> > +./context-coloring/libraries/ert-async.el:;; Copyri= ght (C) 2014
>> >> > Johan
>> >> > Andersson
>> >>
>> >> I think this change is incorrect.=C2=A0 IIUC this is johan.rejeep@gmail.com
>> >> we're talking bout, and he signed the copyright assig= nment forms, so
>> >> the line in ert-async.el should say "Copyright (C) 2= 014 Free Software
>> >> Foundation, Inc" (at which point you won't need = any change to
>> >> copyright_exceptions).
>> >>
>> >>
>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Stefan
>> >
>> >
>
>

--047d7b41890b55695a050e41530f--