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

[Bastien <bzg@gnu.org>]

Achim Gratz <Stromeko@nexgo.de> writes:

> You didn't answer the question of what you want contrib to be or I'm too
> dense to find where.

I want contributed Org libraries to be maintained in a separate Git
repository the same what the GNU ELPA packages are maintained in their
own repository, outside Emacs.

> You keep talking about an Org ELPA that doesn't exist

AFAICT Org ELPA does exist:

http://orgmode.org/elpa.html
http://orgmode.org/elpa/archive-contents
http://orgmode.org/elpa/

What I'm missing?

> and about your
> expectation of unspecified advantages that this might have.  

The main advantages I see:

1. it would clarify the representation of Org's ecosystem for the
   users;

2. it would make it easier to discover Org contributed packages by
   using the Emacs packaging system facilities;

2. this way we won't need to give write access to Org's core for
   contributors who only maintain a contributed package.

The first two points are the most important, since we never had
problems with contributors.

M-x list-packages RET is the way users expect to find packages.
A new Org exporter should be listed there, not in within some
obscure "org-plus-contrib" package, and not from a directory.

> Again,
> please clearly state what you want this to be as well as why and how it
> is better than what we have now.

I want this this to be a separate Git repo the same way GNU ELPA is a
separate git repo from Emacs (that's the "what"); because it is better
in terms of discoverability (M-x list-packages RET); and this is better
because it reuses what users have learned to use recently.

>>> If you are suggesting to remove the history of contrib from Org's repo,
>>> then I'm against it.  
>>
>> Why?
>
> For starters, that would require everyone maintaining their own branches
> to also migrate (or abandon) them.  You'd need a _really_ good reason to
> do this and so far I see none.

If that's a blocker, we can move forward only removing the contrib/
directory, not the Git history.  I'm fine with this, and that's much
easier.

I feel like I won't convince you and this is not my decision, so
I'll stop advocating for this to happen, I just hope it will.

-- 
 Bastien