>> >> 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