Re: Requesting review before pushing patch to ELPA

[Artur Malabarba <bruce.connor.am@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5610 bytes --]

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 <bruce.connor.am@gmail.com>:

> 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 <jackson@jacksonrayhamilton.com
> >:
> > 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
> >> <jackson@jacksonrayhamilton.com>:
> >> > 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
> >> > <monnier@iro.umontreal.ca>
> >> > 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
> >> >
> >> >
> >
> >
>

[-- Attachment #2: Type: text/html, Size: 7807 bytes --]