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:15:19 +0000 Message-ID: References: Reply-To: bruce.connor.am@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1423048567 14710 80.91.229.3 (4 Feb 2015 11:16:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 4 Feb 2015 11:16:07 +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:15:53 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 1YIxw0-0002Pe-76 for ged-emacs-devel@m.gmane.org; Wed, 04 Feb 2015 12:15:52 +0100 Original-Received: from localhost ([::1]:35637 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIxvz-0005U9-JW for ged-emacs-devel@m.gmane.org; Wed, 04 Feb 2015 06:15:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49292) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIxvZ-0005Tq-Ka for emacs-devel@gnu.org; Wed, 04 Feb 2015 06:15:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YIxvV-00042N-63 for emacs-devel@gnu.org; Wed, 04 Feb 2015 06:15:25 -0500 Original-Received: from mail-oi0-x230.google.com ([2607:f8b0:4003:c06::230]:55154) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIxvU-00042C-VR for emacs-devel@gnu.org; Wed, 04 Feb 2015 06:15:21 -0500 Original-Received: by mail-oi0-f48.google.com with SMTP id v63so726661oia.7 for ; Wed, 04 Feb 2015 03:15:20 -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=xeT+fyJOs0oL5+U3k/JH97FobQYvc6E1W6CFWPpj3dY=; b=vzaKRGa0s9A/TD6LHIvmmJbdFt1y2vY2qAeerSOaNur0LEWQ5OYoBAVs0RNm7dUF3l AGp6xdfQ5umVDlPu+LFsD4tnq9UuskiVbT5GaZjeL9PY+yAZ1p9thxRLUPaea8NamwQ0 5Nxgnuy+G2s7QsARBKh1AbngMAZybYVfM2IEwAh7Hs4n7LTAU/fJ8TYijuLBZVHkd9Pt EsCClJk7bI5wm1b/y7gn47UBzPMp06ADifBhva/HA2Ib1eCVcN3APwGHjM9WE7HlbM27 NzSAUtqQXaccEcMqYjeSRPHB/zmdWb3pUwR8/ibBao7yrP1aZufb0x6HyObcR8M62vDx SgqA== X-Received: by 10.182.231.230 with SMTP id tj6mr18859203obc.58.1423048519883; Wed, 04 Feb 2015 03:15:19 -0800 (PST) Original-Received: by 10.76.125.1 with HTTP; Wed, 4 Feb 2015 03:15:19 -0800 (PST) In-Reply-To: X-Google-Sender-Auth: _-frnnyavkrPdhjubnaJ3EAAGvo X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4003:c06::230 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:182364 Archived-At: 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 > 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 >> > >> > > >