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

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

[Nicolas Goaziou]

Hello,

"ox-koma-letter" is an export back-end living in contrib, which, as you
may know, allows to easily produce letters from Org. I think this is
a nice feature to have[fn:1]. Should we have it in core?

There is one thing to consider, though: Viktor Rosenfeld (Cc'ed)
contributed a significant number of lines of code to the file but hasn't
signed FSF papers, AFAIK.

WDYT?


Regards,

[fn:1] Luis Anaya's ox-groff.el seems to provide similar features but
I haven't tested it. Though, AFAICS, Groff is more limited than LaTeX.

-- 
Nicolas Goaziou

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

[Rasmus]

Hi Nicolas,

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> "ox-koma-letter" is an export back-end living in contrib, which, as you
> may know, allows to easily produce letters from Org. I think this is
> a nice feature to have[fn:1]. Should we have it in core?

I would be happy to see this!  I have some outstanding patches posted
on this list that need some minor fixes before being applied.

If this happens, I would be happy to receive any comments regarding
the quality of the code.

> There is one thing to consider, though: Viktor Rosenfeld (Cc'ed)
> contributed a significant number of lines of code to the file but hasn't
> signed FSF papers, AFAIK.

I only saw Alan in the Cc, but Viktor is in the Cc to this email.

> [fn:1] Luis Anaya's ox-groff.el seems to provide similar features but
> I haven't tested it. Though, AFAICS, Groff is more limited than LaTeX.

Some of interface-choices of ox-koma are inspired by ox-groff, though
documents are not compatible. By now I think ox-koma-letter is
slightly more feature-rich.  KOMA-scrip is probably more feature rich
than groff, though only a subset of the features are available through
ox-koma-letter.

-- 
I almost cut my hair, it happened just the other day

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

[Carsten Dominik]

On 18 Jan 2014, at 00:08, Nicolas Goaziou <n.goaziou@gmail.com> wrote:

> Hello,
> 
> "ox-koma-letter" is an export back-end living in contrib, which, as you
> may know, allows to easily produce letters from Org. I think this is
> a nice feature to have[fn:1]. Should we have it in core?

I like the koma-letter class and have no objections to move it onto core.


> 
> There is one thing to consider, though: Viktor Rosenfeld (Cc'ed)
> contributed a significant number of lines of code to the file but hasn't
> signed FSF papers, AFAIK.

Viktor, what is your positions on this?

- Carsten

> 
> WDYT?
> 
> 
> Regards,
> 
> [fn:1] Luis Anaya's ox-groff.el seems to provide similar features but
> I haven't tested it. Though, AFAICS, Groff is more limited than LaTeX.
> 
> -- 
> Nicolas Goaziou
> 

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

[Alan Schmitt]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Hello,
>
> "ox-koma-letter" is an export back-end living in contrib, which, as you
> may know, allows to easily produce letters from Org. I think this is
> a nice feature to have[fn:1]. Should we have it in core?
>
> There is one thing to consider, though: Viktor Rosenfeld (Cc'ed)
> contributed a significant number of lines of code to the file but hasn't
> signed FSF papers, AFAIK.
>
> WDYT?

I'm (obviously) all for it. And I want to stress that both Viktor and
Rasmus contributed a lot to this code (and Nicolas too, of course). I'm
just a minor contributor who uses this a lot and got lucky to be listed
in the credits ;-)

Alan

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

[Bastien]

Carsten Dominik <carsten.dominik@gmail.com> writes:

>> "ox-koma-letter" is an export back-end living in contrib, which, as you
>> may know, allows to easily produce letters from Org. I think this is
>> a nice feature to have[fn:1]. Should we have it in core?
>
> I like the koma-letter class and have no objections to move it onto
> core.

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

I have no objection against this move but I'd like to consider it move
from a wider perspective/proposal, then decide afterwards.

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

The benefits:

- Org's core = 1 repo which contains only Org's core

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

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

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?

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.

-- 
 Bastien

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

[Achim Gratz]

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

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

[Bastien]

Achim Gratz <Stromeko@nexgo.de> writes:

> The first question is what do we want contrib to be?  

So let's start with this one.

contrib/ *was* a staging area for stuff that were meant to go into
core at some point---i.e. when they get mature enough and when the
copyright assignments are sorted out.

For most libraries, contrib/ *is not* a staging area anymore.

So for now, having stuff in contrib/ means something like

  "These libraries are contributed by Org users and you can get their
  latest version by downloading the .tar.gz, the .zip, by cloning Org
  repo or by install org-plus-contrib from Org ELPA."

The core idea is that stuff from contrib get more love than random
github Org libraries: Org maintainers do fix stuff in there from time
to time (compiler warnings, etc.)

I think:

1) this core idea is fine, but I'm for applying it to Org ELPA instead
   of the Org contrib/ directory.

2) it would be cleaner if org-in-emacs and org-repo would be the same.

My point of view is that of the users, who get easily lost in those
distinctions. 


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

It is *not* a staging area only.

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

I'm against dumping not-for-core libraries.

And that precisely because it's good to have libraries close to
Org's list/devs that I'd prefer the Org ELPA solution.

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

Why?

-- 
 Bastien

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

[Achim Gratz]

Bastien writes:
>> The first question is what do we want contrib to be?  
>
> So let's start with this one.
[…]

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

You keep talking about an Org ELPA that doesn't exist and about your
expectation of unspecified advantages that this might have.  Again,
please clearly state what you want this to be as well as why and how it
is better than what we have now.

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


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

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

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

[Bastien]

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

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

[Achim Gratz]

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

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

[Bastien]

Achim Gratz <Stromeko@nexgo.de> writes:

> So, the in-core exporters don't need to
> be discovered, but the contrib exporters all need their own ELPA
> package?

You state it very well.

In-core exporters are what people expect to be included in Emacs,
easily activated without downloading and installing any new library.

The contributed exporters are those that you would find by using
M-x list-packages RET after adding Org ELPA.

IIUC your suggestion is to keep contrib/ for things that are good
candidates for core, and to remove non-candidate libraries.

My suggestion is to get rid of the contrib/ directory and to have
a separate Git repository with libraries available from Org ELPA.

This Git repository will receive more attention that sparse code
on repositories on the World Wild Web.

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

To comply with the way people do use M-x list-packages RET today.

-- 
 Bastien

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

[Rasmus]

Bastien <bzg@gnu.org> writes:

> Achim Gratz <Stromeko@nexgo.de> writes:
>
>> So, the in-core exporters don't need to
>> be discovered, but the contrib exporters all need their own ELPA
>> package?
>
> You state it very well.
>
> In-core exporters are what people expect to be included in Emacs,
> easily activated without downloading and installing any new library.
>
> The contributed exporters are those that you would find by using
> M-x list-packages RET after adding Org ELPA.
>
> IIUC your suggestion is to keep contrib/ for things that are good
> candidates for core, and to remove non-candidate libraries.
>
> My suggestion is to get rid of the contrib/ directory and to have
> a separate Git repository with libraries available from Org ELPA.
>
> This Git repository will receive more attention that sparse code
> on repositories on the World Wild Web.
>
>> I understand that you want the repo split, I just don't understand
>> what for.
>
> To comply with the way people do use M-x list-packages RET today.

I don't have strong opinions on this, but I like the "batteries
included" way that Org is distributed at the moment, i.e. with contrib
under Org.

ATM ELPA contains little info about packages and often I need to track
down some git repo to read more about the package before installing.

–Rasmus

-- 
El Rey ha muerto. ¡Larga vida al Rey!

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

[Eric Schulte]

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

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

[Detlef Steuer]

> My suggestion is to get rid of the contrib/ directory and to have
> a separate Git repository with libraries available from Org ELPA.

I really like that the important contribs are included in my orgmode 
GIT checkout. It would make it harder to _start_ with orgmode if the
repo woud be splitted. 

May be your suggestions are obvious for hard-core emacsers. But
nowadays I *think* there are a lot of orgmode users who use emacs just
because of orgmode. Even ELPA is no obvious choice if you mix the
package manager of your beloved distro with it.

For me as a user the current state of affairs works as expected. So,
please, only change it if you feel it is a must.

Detlef

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

[Bastien]

Thanks for sharing your thoughts on this and clarifying the
possibilities.

Eric Schulte <schulte.eric@gmail.com> writes:

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

Agreed, (1) and (2) can be done independently.

But if we do (2), I think it's better to have org-contrib as a
separate repo, because it is simpler.

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

The separate repo could be a submodule of Org's core repo and its
contents could even make it into the .tar.gz and .zip files.

The makefile could let users do "make contrib" to retrieve contributed
packages into contrib/.

The idea would still be to encourage people to use the Org ELPA
packaging facility to install contributed packages.

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

To me, "Org ELPA" is quite an endorsement too, the same way that GNU
ELPA packages are endorsed by the GNU project and the Emacs team.

Actually, we should ask contributors of contrib what they think.

> 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 agree this may be lot of work.  I'm willing to look more into GNU
ELPA to see how it is done there, and how we could do this.

> I hope this is constructive.

It is, thanks.

I understand the "all batteries included" argument very well, and the
point is *not* to take things away from the users.

It is to clarify the current setup, get more Org contributions into
Org ELPA (I guess a lot of github stuff could go there because devs
would be clear about what is the policy---for now they are not sure
whether stuff in contrib needs a copyright assignment or not) and to
prepare for one of these possibilities:

1) In the long run, maybe Org will be a submodule of Emacs Git repo.
   Completely hypothetical, but that will not be feasible if the Git
   repo contains contrib/.

2) In a far far galaxy, maybe Org will be stable enough to be
   maintained only in Emacs.  So... what then ?  Some contrib/
   directory lost in the space ?

I hope it tells more about where I come from,

-- 
 Bastien

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

[Nick Dokos]

Bastien <bzg@gnu.org> writes:
>
> The separate repo could be a submodule of Org's core repo and its
> contents could even make it into the .tar.gz and .zip files.
>

I'm not sure that submodules are robust enough.  I tried using them for
a small project and found them wanting (that was a couple of years ago, so
there may be have changes to git to make things better). I then used the
alternate strategy described in Chacon's book (git subtree merging) and
ended up in a tangle: I had to tease the repos apart manually. I now do
things more manually, but (to me) more transparently.

This may very well have been me tripping over my shoelaces of course, and
a more knowledgeable git admin might have been able to make things work
better than I did. But I think it would behoove us to step into those
waters with a fair amount of caution, a backup strategy and lots of
experimentation and documentation, before we take the leap.

Nick

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

[Bastien]

Hi Nick,

Nick Dokos <ndokos@gmail.com> writes:

> But I think it would behoove us to step into those
> waters with a fair amount of caution, a backup strategy and lots of
> experimentation and documentation, before we take the leap.

I completely agree.  I would consider using git submodules iff the
users don't have to deal with them.

-- 
 Bastien

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

[Achim Gratz]

Bastien writes:
> IIUC your suggestion is to keep contrib/ for things that are good
> candidates for core, and to remove non-candidate libraries.

No, my suggestion is to look at the things in contrib and decide what to
do with them.  A few of those things will never be in core nor will they
be in ELPA, simply because they aren't eLisp.  So if contrib goes away
per your proposal, then where do these files go?  Moving to the lisp
sources, there's a bunch that look&feel like they should be in core.  We
should look at what's the holdup, fix it and move them into core.  Not
all at once, mind you.  Then there are perhaps a few files left that for
whatever reason aren't fit for core and never will be (license,
copyright, support for non-free software, whatever).  Again we should
decide what to do with those.  If nobody works on them my personal
opinion is that these should find a different home than the Org project.

> My suggestion is to get rid of the contrib/ directory and to have
> a separate Git repository with libraries available from Org ELPA.
>
> This Git repository will receive more attention that sparse code
> on repositories on the World Wild Web.

That assumption may very well turn out to be invalid.  If you'd split
off something like Babel it may very well create a live community, but
fragmenting contrib into separate repos could drain any signs of life
from them.


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

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

[Achim Gratz]

Bastien writes:
> The separate repo could be a submodule of Org's core repo and its
> contents could even make it into the .tar.gz and .zip files.

I'd guess you haven't worked with submodules yet.

> 1) In the long run, maybe Org will be a submodule of Emacs Git repo.
>    Completely hypothetical, but that will not be feasible if the Git
>    repo contains contrib/.
>
> 2) In a far far galaxy, maybe Org will be stable enough to be
>    maintained only in Emacs.  So... what then ?  Some contrib/
>    directory lost in the space ?

Both options are undesirable, IMHO.  If you want to do something
sensible from the Emacs side, then get Emacs to spin out all "built-in"
packages that are not necessary for dumping Emacs to GNU ELPA and then
bundle them into the release from there.  That will demonstrate the
shortcomings of package manager as it exists today very clearly and
hopefully provide a strong push to fix it.


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

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

[Bastien]

Achim Gratz <Stromeko@nexgo.de> writes:

> If you'd split
> off something like Babel it may very well create a live community, but
> fragmenting contrib into separate repos could drain any signs of life
> from them.

Just to be clear: I'm not suggesting to split each library in contrib/
into its own repository, I'm suggesting to use a separate repo for all
Elisp stuff in contrib.

-- 
 Bastien

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

[Bastien]

Achim Gratz <Stromeko@nexgo.de> writes:

>> 1) In the long run, maybe Org will be a submodule of Emacs Git repo.
>>    Completely hypothetical, but that will not be feasible if the Git
>>    repo contains contrib/.
>>
>> 2) In a far far galaxy, maybe Org will be stable enough to be
>>    maintained only in Emacs.  So... what then ?  Some contrib/
>>    directory lost in the space ?
>
> Both options are undesirable, IMHO.

The first does not depend on us, the second one will be desirable
when all Org committers will be Emacs committers too, and when the
pace of Emacs release will be fast enough to cope with that of Org.
Of course, this is only the way I see it.

-- 
 Bastien

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

[Bastien]

Hi all,

Bastien <bzg@gnu.org> writes:

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

Here is another way to evaluate this proposal: imagine we don't
have the contrib/ directory and we want to promote some external
Org libraries but don't want to include them into core.  How would
we proceed, then?  By creating a contrib/ directory or by adapting
the Org ELPA archive to welcome those libraries?

It'd be for creating an Org ELPA repository.

Granted, this reasoning does not take into account the amount of
work needed to adapt the Org ELPA and migrate the current libraries,
but I think it's still valid.

Now consider this my last attempt at convincing anyone :)

-- 
 Bastien

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

[Nicolas Goaziou]

Hello,

Bastien <bzg@gnu.org> writes:

> Bastien <bzg@gnu.org> writes:
>
>> My suggestion: convert contrib/lisp/ libraries into Org ELPA packages
>> and expurge the the contrib/ Git history from Org's repo.
>
> Here is another way to evaluate this proposal: imagine we don't
> have the contrib/ directory and we want to promote some external
> Org libraries but don't want to include them into core.

As a reminder, the initial point of this thread was to suggest that
providing a way to create letters is a /core/ feature for Org. So this
is orthogonal to the contrib/ vs ELPA package discussion.


Regards,

-- 
Nicolas Goaziou

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

[Bastien]

Hi Nicolas,

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> As a reminder, the initial point of this thread was to suggest that
> providing a way to create letters is a /core/ feature for Org. So this
> is orthogonal to the contrib/ vs ELPA package discussion.

Yes, this is orthogonal.

My suggestion is to ask Emacs maintainers, but of course I'm fine if
Carsten decides otherwise.

-- 
 Bastien

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

[Nicolas Goaziou]

Hello,

Bastien <bzg@altern.org> writes:

> My suggestion is to ask Emacs maintainers

Why this suggestion? We recently introduced "ob-coq.el" in core without
asking Emacs maintainers beforehand.


Regards,

-- 
Nicolas Goaziou

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

[Bastien]

Hi,

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Why this suggestion?

To get Emacs core maintainers opinions on this and clarify if we can
expand Org features at will or if they want to be control that somehow.

> We recently introduced "ob-coq.el" in core without
> asking Emacs maintainers beforehand.

That's different: supporting as many programming languages is a core
feature of Babel, while supporting as many export target as possible
should not be a core feature of Emacs IMO, it should stay as a nice
facility of the Org ecosystem.

The second part of the paragraph above ("while...") is where I'd be
interested to hear about what Emacs core maintainers think.

If you're fine with this, I'll raise the topic on both emacs-devel
and this list.

-- 
 Bastien

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

[Nicolas Goaziou]

Bastien <bzg@gnu.org> writes:

> To get Emacs core maintainers opinions on this and clarify if we can
> expand Org features at will or if they want to be control that
> somehow.

AFAICT, we never asked Emacs maintainers before adding a feature to Org,
and I don't think the number of export targets in core grew
exponentially lately.

Also, I don't see why Emacs maintainers would want to limit features
provided in an Emacs library, as long as it doesn't impedes GNU goals
and copyright issues are sorted out (which is not yet the case of the
file we're talking about).

> That's different: supporting as many programming languages is a core
> feature of Babel, while supporting as many export target as possible
> should not be a core feature of Emacs IMO, it should stay as a nice
> facility of the Org ecosystem.
>
> The second part of the paragraph above ("while...") is where I'd be
> interested to hear about what Emacs core maintainers think.

Sorry, I cannot understand this argument, since the target is a "tex"
file, and we already export to "tex" files.

> If you're fine with this, I'll raise the topic on both emacs-devel
> and this list.

I suggested this idea because I thought it was a good one. The very fact
that we're still discussing it proves that it isn't as obvious as
I initially thought. That's fine with me.

I will not insist anymore on this topic.


Regards,

-- 
Nicolas Goaziou

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

[Rasmus]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

>> That's different: supporting as many programming languages is a core
>> feature of Babel, while supporting as many export target as possible
>> should not be a core feature of Emacs IMO, it should stay as a nice
>> facility of the Org ecosystem.
>>
>> The second part of the paragraph above ("while...") is where I'd be
>> interested to hear about what Emacs core maintainers think.
>
> Sorry, I cannot understand this argument, since the target is a "tex"
> file, and we already export to "tex" files.

Did we ask about ox-beamer?  If we support the creation of slides why
not letters?  Both are "representations" of LaTeX and extensions of
ox-latex.el.

>> If you're fine with this, I'll raise the topic on both emacs-devel
>> and this list.
>
> I suggested this idea because I thought it was a good one. The very fact
> that we're still discussing it proves that it isn't as obvious as
> I initially thought. That's fine with me.

Based on "google" search, the Worg page for the exporter has some
attention.

   https://startpage.com/do/search?query=koma-script+letter

My — biased — opinion is that ox-koma-letter provides a nice way of
typesetting and structuring letters (compared to the raw tex format),
e.g. here:

   http://orgmode.org/worg/exporters/koma-letter-export.html#sec-1-3
   http://orgmode.org/w/?p=worg.git;a=blob_plain;f=images/ox-koma-letter/koma-letter-new-example.pdf

—Rasmus

-- 
Summon the Mothership!

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

[Thomas S. Dye]

Aloha all,

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Bastien <bzg@gnu.org> writes:
>
>> To get Emacs core maintainers opinions on this and clarify if we can
>> expand Org features at will or if they want to be control that
>> somehow.
>
> AFAICT, we never asked Emacs maintainers before adding a feature to Org,
> and I don't think the number of export targets in core grew
> exponentially lately.
>
> Also, I don't see why Emacs maintainers would want to limit features
> provided in an Emacs library, as long as it doesn't impedes GNU goals
> and copyright issues are sorted out (which is not yet the case of the
> file we're talking about).
>
>> That's different: supporting as many programming languages is a core
>> feature of Babel, while supporting as many export target as possible
>> should not be a core feature of Emacs IMO, it should stay as a nice
>> facility of the Org ecosystem.
>>
>> The second part of the paragraph above ("while...") is where I'd be
>> interested to hear about what Emacs core maintainers think.
>
> Sorry, I cannot understand this argument, since the target is a "tex"
> file, and we already export to "tex" files.
>
>> If you're fine with this, I'll raise the topic on both emacs-devel
>> and this list.
>
> I suggested this idea because I thought it was a good one. The very fact
> that we're still discussing it proves that it isn't as obvious as
> I initially thought. That's fine with me.
>
> I will not insist anymore on this topic.

IMO, it would be nice if a lightweight markup language like Org
supported sophisticated letter writing out of the box.

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

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

[Bastien]

Hi Nicolas,

Nicolas Goaziou <n.goaziou@gmail.com> writes:

>> If you're fine with this, I'll raise the topic on both emacs-devel
>> and this list.
>
> I suggested this idea because I thought it was a good one. The very fact
> that we're still discussing it proves that it isn't as obvious as
> I initially thought. That's fine with me.

Let me state it clearly: I'm not against including ox-koma-letter.el
in Org's core (then in Emacs), I actually think it is a good addition
(once documented, that is.)

My suggestion is to ask Emacs maintainers about the general policy
regarding new Org/Emacs exporters.  Chances are that they will blindly
trust us, which I'm fine with.  If they have a different opinion, it's
better to hear it now than when we do the merge.

Also remember I *removed* some exporters and other files from Org's
core when releasing 8.0, because I wanted to draw a clearer line: the
current rule is "If an Org feature relies on something that is not
part of Emacs or not part of a standard GNU system, don't include it
into core."  That's why ox-freemind.el and org-mew.el new lives in
contrib/, for example.

For those features, GNU ELPA or some other packages archive (I'm not
insisting on Org ELPA) is a the way to go IMO.  But let's not revisit
this, it's a separate issue.

-- 
 Bastien

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

[Viktor Rosenfeld]

Hi everybody,

sorry for replying so late to this discussion. I stopped following the 
list a while ago. Rasmus was so kind and tracked me down.

Am 18.01.14 19:10, schrieb Carsten Dominik:
>
> On 18 Jan 2014, at 00:08, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
>
>> There is one thing to consider, though: Viktor Rosenfeld (Cc'ed)
>> contributed a significant number of lines of code to the file but hasn't
>> signed FSF papers, AFAIK.
>
> Viktor, what is your positions on this?

I had actually started the copyright assignment process in September but 
did not follow through with it because I did not fully understand the 
document and did not like some of the language. However, I'm willing to 
give it another shot and have sent my questions to the FSF.

FWIW, I think that the copyright assignment process creates a huge 
barrier of entry to contribute to Orgmode and that it's unfortunate that 
one has to jump through hoops like this to contribute actual code 
(whereas other contributions, e.g., documentation, have no such 
obligation attached).

Also, my view of the document, as I understand it, is that it's very 
one-sided and unfair to the developer, specifically the future works and 
indemnification clauses. For the record, I will not sign a document 
containing the indemnification clause as it currently stands.

Cheers,
Viktor

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

[Thomas S. Dye]

Aloha Viktor,

Viktor Rosenfeld <listuser36@gmail.com> writes:

> Also, my view of the document, as I understand it, is that it's very
> one-sided and unfair to the developer, specifically the future works
> and indemnification clauses. For the record, I will not sign a
> document containing the indemnification clause as it currently stands.

FWIW, as a small businessman, the indemnification clause looks fairly
standard to me.  The contracts for archaeological services that we
routinely sign typically have a clause like this, usually coupled with a
request for a certificate of insurance that specifies the levels of
liability insurance that the business carries.

As I read the clause, FSF is in the position of accepting 1) a code
contribution from a developer, and 2) the developer's assurance that the
contributed code can't be claimed as property by a third party.  It
seems prudent that, in the event of a successful property claim by a
third party to a piece of code contributed by a developer, the developer
who gave the false assurance should be held responsible. Otherwise, FSF
might be brought down by copyleft opponents who knowingly contribute
code to which others have property rights in order to create a basis for
lawsuits.

From my point of view, the problem is the extent to which property
rights structure relationships in our society--an extent unprecedented
in history.  I applaud FSF for its efforts to create computer software
to which we all have a claim not to be excluded from its use or
enjoyment. 

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

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

[Rasmus]

Viktor Rosenfeld <listuser36@gmail.com> writes:

> sorry for replying so late to this discussion. I stopped following the
> list a while ago. Rasmus was so kind and tracked me down.
>
> Am 18.01.14 19:10, schrieb Carsten Dominik:
>>
>> On 18 Jan 2014, at 00:08, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
>>
>>> There is one thing to consider, though: Viktor Rosenfeld (Cc'ed)
>>> contributed a significant number of lines of code to the file but hasn't
>>> signed FSF papers, AFAIK.
>>
>> Viktor, what is your positions on this?
>
> I had actually started the copyright assignment process in September
> but did not follow through with it because I did not fully understand
> the document and did not like some of the language. However, I'm
> willing to give it another shot and have sent my questions to the FSF.

Thanks Viktor; let us know how it goes.

Bastien and Carsten(?), before Viktor goes through too many hoops,
perhaps you could indicate where you minds settled on
the—potential—inclusion of ox-koma-letter.el.

Cheers,
Rasmus

-- 
C is for Cookie

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

[Viktor Rosenfeld]

Hi Tom,

Am 17.02.14 22:56, schrieb Thomas S. Dye:

> FWIW, as a small businessman, the indemnification clause looks fairly
> standard to me.  The contracts for archaeological services that we
> routinely sign typically have a clause like this, usually coupled with a
> request for a certificate of insurance that specifies the levels of
> liability insurance that the business carries.
>
> As I read the clause, FSF is in the position of accepting 1) a code
> contribution from a developer, and 2) the developer's assurance that the
> contributed code can't be claimed as property by a third party.  It
> seems prudent that, in the event of a successful property claim by a
> third party to a piece of code contributed by a developer, the developer
> who gave the false assurance should be held responsible. Otherwise, FSF
> might be brought down by copyleft opponents who knowingly contribute
> code to which others have property rights in order to create a basis for
> lawsuits.

Thanks for your reply. I was hoping to get some feedback on how other 
Orgmode contributors see this issue (although this list is obviously 
self-selective). The problem I have is that I'm not a lawyer or a 
businessman and not a native English speaker. I do know enough though 
not to lightly sign documents I don't fully understand.

At this point, I'm considering to actually get proper legal advice about 
this form, because I'm not satisfied in the state of affairs where I 
have stopped participating in the Orgmode community because I do not 
understand the copyright assignment form.

Cheers,
Viktor

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

[Rasmus]

Viktor Rosenfeld <listuser36@gmail.com> writes:

> Hi Tom,
>
> Am 17.02.14 22:56, schrieb Thomas S. Dye:
>
>> FWIW, as a small businessman, the indemnification clause looks fairly
>> standard to me.  The contracts for archaeological services that we
>> routinely sign typically have a clause like this, usually coupled with a
>> request for a certificate of insurance that specifies the levels of
>> liability insurance that the business carries.
>>
>> As I read the clause, FSF is in the position of accepting 1) a code
>> contribution from a developer, and 2) the developer's assurance that the
>> contributed code can't be claimed as property by a third party.  It
>> seems prudent that, in the event of a successful property claim by a
>> third party to a piece of code contributed by a developer, the developer
>> who gave the false assurance should be held responsible. Otherwise, FSF
>> might be brought down by copyleft opponents who knowingly contribute
>> code to which others have property rights in order to create a basis for
>> lawsuits.
>
> Thanks for your reply. I was hoping to get some feedback on how other
> Orgmode contributors see this issue (although this list is obviously
> self-selective). The problem I have is that I'm not a lawyer or a
> businessman and not a native English speaker. I do know enough though
> not to lightly sign documents I don't fully understand.

Perhaps FSFE would be able to shed some light on the issue (EU-based).
Or Software Freedom Conservancy (US-based).  I don't have further
insights.

—Rasmus

-- 
May contains speling mistake

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

[Alan L Tyree]

On 21/02/14 00:29, Rasmus wrote:
> Viktor Rosenfeld <listuser36@gmail.com> writes:
>
>> Hi Tom,
>>
>> Am 17.02.14 22:56, schrieb Thomas S. Dye:
>>
>>> FWIW, as a small businessman, the indemnification clause looks fairly
>>> standard to me.  The contracts for archaeological services that we
>>> routinely sign typically have a clause like this, usually coupled with a
>>> request for a certificate of insurance that specifies the levels of
>>> liability insurance that the business carries.
>>>
>>> As I read the clause, FSF is in the position of accepting 1) a code
>>> contribution from a developer, and 2) the developer's assurance that the
>>> contributed code can't be claimed as property by a third party.  It
>>> seems prudent that, in the event of a successful property claim by a
>>> third party to a piece of code contributed by a developer, the developer
>>> who gave the false assurance should be held responsible. Otherwise, FSF
>>> might be brought down by copyleft opponents who knowingly contribute
>>> code to which others have property rights in order to create a basis for
>>> lawsuits.
>> Thanks for your reply. I was hoping to get some feedback on how other
>> Orgmode contributors see this issue (although this list is obviously
>> self-selective). The problem I have is that I'm not a lawyer or a
>> businessman and not a native English speaker. I do know enough though
>> not to lightly sign documents I don't fully understand.
> Perhaps FSFE would be able to shed some light on the issue (EU-based).
> Or Software Freedom Conservancy (US-based).  I don't have further
> insights.
>
> —Rasmus
>
FWIW, most book publishing contracts that I have seen have something 
similar. An example:

"The Authors warrant to the Publishers that the Work will in no way
whatever violate any existing Copyright (except as notified under Clause
7(b)), and that it will contain nothing of a libellous or scandalous
character. The Authors shall indemnify the Publishers against any claims,
actions, loss or damage including costs and expenses incurred by the
Publishers as a result of any breach of the present warranty."

I imagine that quite a few members of this list have signed something 
similar.

Cheers,
Alan


-- 
Alan L Tyree                    http://www2.austlii.edu.au/~alan
Tel:  04 2748 6206              sip:typhoon@iptel.org

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

[Bastien]

Hi Viktor,

Viktor Rosenfeld <listuser36@gmail.com> writes:

> At this point, I'm considering to actually get proper legal advice
> about this form, because I'm not satisfied in the state of affairs
> where I have stopped participating in the Orgmode community because I
> do not understand the copyright assignment form.

Let us know how it goes.

Until your are 100% confident that signing the FSF paper is fine for
you, we won't consider moving ox-koma-letter.el into core.  (I fully
respect the decision *not* to sign the papers.)

Whether we should move ox-koma-letter.el into Org's core or into the
GNU ELPA archive is a separate issue, since both require that you sign
the papers.

Thanks,

-- 
 Bastien

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

[Greg Troxel]

[-- Attachment #1: Type: text/plain, Size: 941 bytes --]


Viktor Rosenfeld <listuser36@gmail.com> writes:

> FWIW, I think that the copyright assignment process creates a huge
> barrier of entry to contribute to Orgmode and that it's unfortunate
> that one has to jump through hoops like this to contribute actual code
> (whereas other contributions, e.g., documentation, have no such
> obligation attached).
>
> Also, my view of the document, as I understand it, is that it's very
> one-sided and unfair to the developer, specifically the future works
> and indemnification clauses. For the record, I will not sign a
> document containing the indemnification clause as it currently stands.

I agree that the assignment process is a big barrier; it's personally
kept me from starting down the path to contributing to several projects.
In particular indemnification is problematic.

But, org-mode is the tail, and it's unlikely emacs will decide to stop
requiring assignment because of anyone here.

[-- Attachment #2: Type: application/pgp-signature, Size: 180 bytes --]