>>
>> My suggestion is to get rid of the contrib/ directory and to have
>> a separate Git repository with libraries available from Org ELPA.
>>
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.
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.
- 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).
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 hope this is constructive. Best,
Footnotes:
[1] http://orgmode.org/elpa/
[2] http://melpa.milkbox.net/
[3] http://marmalade-repo.org/
--
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D
