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

[Achim Gratz <Stromeko@nexgo.de>]

Bastien writes:
> Shouldn't we ask Emacs maintainers about this?  ox-koma-letter.el into
> core means that bug reports will hit them first, then us.

Debbugs has facilities to redirect such reports to this mailing list
should that become an issue.  Gnus is using this approach AFAIK.

> My suggestion: convert contrib/lisp/ libraries into Org ELPA packages
> and expurge the the contrib/ Git history from Org's repo.

That probably wouldn't work for some of the things in contrib and given
the state of other things I'd question anyone would spend the effort to
properly package them for ELPA.  If you're suggesting to build a
separate ELPA infrastructure just for Org, I don't see this happening —
there'd be a lot of churn for no discernible benefit.  Folks wanting to
develop their stuff as external packages can already do that.

> The benefits:
>
> - Org's core = 1 repo which contains only Org's core

I don't see what you're getting at here, you'll have to explain.

> - It will ease the sync between Org and Emacs when Emacs will use Git.

Not.  You keep looking for silver bullets, there are none.  Even if it
were the case, it probably shouldn't influence the decision about what
to do with contrib.

> - We can handle Org ELPA the same way GNU ELPA is currently handled
>   (giving a separate write access to Org ELPA contributors.)

We could already do that by restricting commits from certain committers
to contrib/… but that would suggest there are "lesser" committers and I
think Org shouldn't segregate in that manner.

> Then installing Org external packages is as easy as using the
> `list-packages'.
>
> If we were using the setup described above, would we still need to
> move ox-koma-letter.el into core?
>
> Independantly of that question, do you think it would make sense
> to move toward the above setup?

The first question is what do we want contrib to be?  If it's a staging
area for things that are not-quite-ready yet, then these things should
either be removed if they aren't getting finished or moved into core
when they are.  Plus, since maint goes to Emacs, but master is not, it
should be in master as soon as the copyright questions are resolved.

If it's becoming a dump of stuff that will never make it into core
because it isn't acceptable for Emacs proper for whatever reason, then
I'd reason that it should be removed as well, independently of whether
it's kept alive outside of Org or not.

> If so, we would need some Git guru (Achim?) to help with filtering
> the Org repo, and I could help with setting up the Org ELPA packages.

If you are suggesting to remove the history of contrib from Org's repo,
then I'm against it.  Duplicating the history of contrib into a
hypothetical new Git repo is possible, but then why split off contrib in
the first place?


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

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra