From mboxrd@z Thu Jan 1 00:00:00 1970 From: Achim Gratz Subject: Re: [RFC] Move ox-koma-letter into core? Date: Sun, 19 Jan 2014 15:03:23 +0100 Message-ID: <87mwisrrv8.fsf@Rainer.invalid> References: <878uueciku.fsf@gmail.com> <55F46D73-2430-4831-ABE9-D66AE03647E7@gmail.com> <874n50cdnu.fsf@bzg.ath.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:47277) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W4syd-0005oA-5c for emacs-orgmode@gnu.org; Sun, 19 Jan 2014 09:03:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W4syT-0006cF-1H for emacs-orgmode@gnu.org; Sun, 19 Jan 2014 09:03:51 -0500 Received: from plane.gmane.org ([80.91.229.3]:52327) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W4syS-0006c8-QC for emacs-orgmode@gnu.org; Sun, 19 Jan 2014 09:03:40 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1W4syP-0005jR-MH for emacs-orgmode@gnu.org; Sun, 19 Jan 2014 15:03:37 +0100 Received: from pd9eb15df.dip0.t-ipconnect.de ([217.235.21.223]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 19 Jan 2014 15:03:37 +0100 Received: from Stromeko by pd9eb15df.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 19 Jan 2014 15:03:37 +0100 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Bastien writes: > Shouldn't we ask Emacs maintainers about this? ox-koma-letter.el into > core means that bug reports will hit them first, then us. Debbugs has facilities to redirect such reports to this mailing list should that become an issue. Gnus is using this approach AFAIK. > My suggestion: convert contrib/lisp/ libraries into Org ELPA packages > and expurge the the contrib/ Git history from Org's repo. That probably wouldn't work for some of the things in contrib and given the state of other things I'd question anyone would spend the effort to properly package them for ELPA. If you're suggesting to build a separate ELPA infrastructure just for Org, I don't see this happening — there'd be a lot of churn for no discernible benefit. Folks wanting to develop their stuff as external packages can already do that. > The benefits: > > - Org's core = 1 repo which contains only Org's core I don't see what you're getting at here, you'll have to explain. > - It will ease the sync between Org and Emacs when Emacs will use Git. Not. You keep looking for silver bullets, there are none. Even if it were the case, it probably shouldn't influence the decision about what to do with contrib. > - We can handle Org ELPA the same way GNU ELPA is currently handled > (giving a separate write access to Org ELPA contributors.) We could already do that by restricting commits from certain committers to contrib/… but that would suggest there are "lesser" committers and I think Org shouldn't segregate in that manner. > Then installing Org external packages is as easy as using the > `list-packages'. > > If we were using the setup described above, would we still need to > move ox-koma-letter.el into core? > > Independantly of that question, do you think it would make sense > to move toward the above setup? The first question is what do we want contrib to be? If it's a staging area for things that are not-quite-ready yet, then these things should either be removed if they aren't getting finished or moved into core when they are. Plus, since maint goes to Emacs, but master is not, it should be in master as soon as the copyright questions are resolved. If it's becoming a dump of stuff that will never make it into core because it isn't acceptable for Emacs proper for whatever reason, then I'd reason that it should be removed as well, independently of whether it's kept alive outside of Org or not. > If so, we would need some Git guru (Achim?) to help with filtering > the Org repo, and I could help with setting up the Org ELPA packages. If you are suggesting to remove the history of contrib from Org's repo, then I'm against it. Duplicating the history of contrib into a hypothetical new Git repo is possible, but then why split off contrib in the first place? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra