From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bastien Subject: Re: [RFC] Move ox-koma-letter into core? Date: Tue, 21 Jan 2014 11:52:42 +0100 Message-ID: <87iotdhait.fsf@bzg.ath.cx> References: <878uueciku.fsf@gmail.com> <55F46D73-2430-4831-ABE9-D66AE03647E7@gmail.com> <874n50cdnu.fsf@bzg.ath.cx> <87mwisrrv8.fsf@Rainer.invalid> <87k3dwaw98.fsf@bzg.ath.cx> <87r482wo2k.fsf@Rainer.invalid> <87ha8yjzeb.fsf@bzg.ath.cx> <87eh42wju4.fsf@Rainer.invalid> <874n4yju56.fsf@bzg.ath.cx> <87eh4259r2.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:47980) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5Ywx-0006X8-MX for emacs-orgmode@gnu.org; Tue, 21 Jan 2014 05:53:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W5Ywp-0007jP-7x for emacs-orgmode@gnu.org; Tue, 21 Jan 2014 05:52:55 -0500 Received: from mail-wi0-x235.google.com ([2a00:1450:400c:c05::235]:61063) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5Ywo-0007jF-TV for emacs-orgmode@gnu.org; Tue, 21 Jan 2014 05:52:47 -0500 Received: by mail-wi0-f181.google.com with SMTP id hi8so4173483wib.8 for ; Tue, 21 Jan 2014 02:52:46 -0800 (PST) In-Reply-To: <87eh4259r2.fsf@gmail.com> (Eric Schulte's message of "Mon, 20 Jan 2014 19:50:09 -0700") 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: Eric Schulte Cc: Achim Gratz , emacs-orgmode@gnu.org Thanks for sharing your thoughts on this and clarifying the possibilities. Eric Schulte writes: > If I understand correctly you are suggesting two thing. > > 1. We remove the contrib/ directory, and host the contributed packages > in a single new org-contrib (or somesuch) repository. > > 2. We begin packaging each contrib/ file as a separate ELPA package. > This would entail; > > a. Enhancing the functionality of the existing Org-mode elpa site [1] > to host these new packages, and possibly to provide some nicer > package list or sort/search functionality. > > b. Adding some sort of automated (e.g., Makefile) support to extract > these package from either the existing org-mode or a new > org-contrib repository. > > c. Possibly pulling package metadata (e.g., license, author, > requirements, keywords, summary, etc...) automatically from the > contrib source files in the manner of MELPA [2] and Marmalade [3]. > > I believe these two suggestions could be implemented independently from > each other and I do not see why they need by related. Agreed, (1) and (2) can be done independently. But if we do (2), I think it's better to have org-contrib as a separate repo, because it is simpler. > My thoughts on them are as follows. > > 1. I don't like this suggestion because; > > - I like having all contributed packages easily at hand, and I like > that most people I talk to on this list also have contrib packages > readily at hand. The separate repo could be a submodule of Org's core repo and its contents could even make it into the .tar.gz and .zip files. The makefile could let users do "make contrib" to retrieve contributed packages into contrib/. The idea would still be to encourage people to use the Org ELPA packaging facility to install contributed packages. > - It provides a way for Org-mode to "endorse" third party packages, > and it serves as a useful incubator for functionality which is > headed for the core but may need wider testing (e.g., code block > support and the new exporter framework). To me, "Org ELPA" is quite an endorsement too, the same way that GNU ELPA packages are endorsed by the GNU project and the Emacs team. Actually, we should ask contributors of contrib what they think. > 2. I think this suggestion could be nice, although depending on how it > is done it risks both being a large amount of work and duplicating > the already duplicated functionality of MELPA and marmalade (I'm > specifically thinking of automated metadata extraction here). I agree this may be lot of work. I'm willing to look more into GNU ELPA to see how it is done there, and how we could do this. > I hope this is constructive. It is, thanks. I understand the "all batteries included" argument very well, and the point is *not* to take things away from the users. It is to clarify the current setup, get more Org contributions into Org ELPA (I guess a lot of github stuff could go there because devs would be clear about what is the policy---for now they are not sure whether stuff in contrib needs a copyright assignment or not) and to prepare for one of these possibilities: 1) In the long run, maybe Org will be a submodule of Emacs Git repo. Completely hypothetical, but that will not be feasible if the Git repo contains contrib/. 2) In a far far galaxy, maybe Org will be stable enough to be maintained only in Emacs. So... what then ? Some contrib/ directory lost in the space ? I hope it tells more about where I come from, -- Bastien