Re: [RFC] Move ox-koma-letter into core?

[Bastien <bzg@gnu.org>]

Thanks for sharing your thoughts on this and clarifying the
possibilities.

Eric Schulte <schulte.eric@gmail.com> 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