From: Achim Gratz <Stromeko@nexgo.de>
To: emacs-orgmode@gnu.org
Subject: Re: [RFC] Move ox-koma-letter into core?
Date: Mon, 20 Jan 2014 20:10:11 +0100 [thread overview]
Message-ID: <87eh42wju4.fsf@Rainer.invalid> (raw)
In-Reply-To: 87ha8yjzeb.fsf@bzg.ath.cx
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
next prev parent reply other threads:[~2014-01-20 19:10 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-17 23:08 [RFC] Move ox-koma-letter into core? Nicolas Goaziou
2014-01-18 11:55 ` Rasmus
2014-01-18 18:10 ` Carsten Dominik
2014-01-19 13:19 ` Bastien
2014-01-19 14:03 ` Achim Gratz
2014-01-19 14:20 ` Bastien
2014-01-20 17:38 ` Achim Gratz
2014-01-20 18:12 ` Bastien
2014-01-20 19:10 ` Achim Gratz [this message]
2014-01-20 20:05 ` Bastien
2014-01-21 1:12 ` Rasmus
2014-01-21 2:50 ` Eric Schulte
2014-01-21 10:52 ` Bastien
2014-01-21 15:50 ` Nick Dokos
2014-01-21 15:57 ` Bastien
2014-01-21 18:31 ` Achim Gratz
2014-01-21 19:10 ` Bastien
2014-01-21 8:22 ` Detlef Steuer
2014-01-21 18:19 ` Achim Gratz
2014-01-21 19:08 ` Bastien
2014-01-27 14:36 ` Bastien
2014-01-29 13:53 ` Nicolas Goaziou
2014-01-29 14:02 ` Bastien
2014-02-07 10:35 ` Nicolas Goaziou
2014-02-07 10:47 ` Bastien
2014-02-07 17:08 ` Nicolas Goaziou
2014-02-07 17:28 ` Rasmus
2014-02-07 17:37 ` Thomas S. Dye
2014-02-08 13:17 ` Bastien
2014-02-17 19:10 ` Viktor Rosenfeld
2014-02-17 21:56 ` Thomas S. Dye
2014-02-19 20:33 ` Viktor Rosenfeld
2014-02-20 13:29 ` Rasmus
2014-02-20 22:32 ` Alan L Tyree
2014-03-04 9:35 ` Bastien
2014-02-17 22:25 ` Rasmus
2014-03-10 18:12 ` Greg Troxel
2014-01-18 21:15 ` Alan Schmitt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87eh42wju4.fsf@Rainer.invalid \
--to=stromeko@nexgo.de \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).