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

[Achim Gratz <Stromeko@nexgo.de>]

Bastien writes:
> 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.

That's the how, not the what.

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

The whole infrastructure necessary to meaningfully host more than the
two packages that are on offer today.  These are (as you well know)
simply extra build targets from Orgmode Git.  If you're starting to have
more packages from different sources, you'll need something a lot more
sophisticated.

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

It doesn't clarify anything to me.

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

Configure ELPA and Marmalade and see if you "discover" anything easily.
If you think that works, add MELPA and try again.  Package manager in
it's current state isn't really a good tool to deal with more than about
two dozen packages.

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

I don't see the problem here, really.  The Git way of dealing with this
is actually to have those maintainers set up their own cloned repo,
maintain their stuff on a branch and send whoever maintains upstream a
pull request when they are ready.  If they don't have a publically
accessible repo, then they send it as a Git patch.

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

Sorry, that is twisted logic.  So, the in-core exporters don't need to
be discovered, but the contrib exporters all need their own ELPA
package?

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

Again, you've already decided the "how" and are wrapping your arguments
around that to make it appear as a "what".  That Emacs ELPA is a
separate repo is largely an historical accident and doesn't really have
much of a technical reason.  It could have been included in Emacs Git if
that was already existing at the time or it could have been a single
repo for each package in ELPA.  In the same way, just slicing off
contrib into a second Git repo doesn't buy you anything noteworthy you
can't have today in a single repo, it is still the same set of sources.

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

Yes.

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

I understand that you want the repo split, I just don't understand what
for.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada