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

2014-03-10 Thread Greg Troxel

Viktor Rosenfeld listuse...@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.


pgpvPkHTOryMK.pgp
Description: PGP signature


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

2014-03-04 Thread Bastien
Hi Viktor,

Viktor Rosenfeld listuse...@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: [O] [RFC] Move ox-koma-letter into core?

2014-02-20 Thread Rasmus
Viktor Rosenfeld listuse...@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: [O] [RFC] Move ox-koma-letter into core?

2014-02-20 Thread Alan L Tyree


On 21/02/14 00:29, Rasmus wrote:

Viktor Rosenfeld listuse...@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 Tyreehttp://www2.austlii.edu.au/~alan
Tel:  04 2748 6206  sip:typh...@iptel.org




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

2014-02-19 Thread 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: [O] [RFC] Move ox-koma-letter into core?

2014-02-17 Thread 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.goaz...@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: [O] [RFC] Move ox-koma-letter into core?

2014-02-17 Thread Thomas S. Dye
Aloha Viktor,

Viktor Rosenfeld listuse...@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: [O] [RFC] Move ox-koma-letter into core?

2014-02-17 Thread Rasmus
Viktor Rosenfeld listuse...@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.goaz...@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: [O] [RFC] Move ox-koma-letter into core?

2014-02-08 Thread Bastien
Hi Nicolas,

Nicolas Goaziou n.goaz...@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: [O] [RFC] Move ox-koma-letter into core?

2014-02-07 Thread Bastien
Hi,

Nicolas Goaziou n.goaz...@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: [O] [RFC] Move ox-koma-letter into core?

2014-02-07 Thread Nicolas Goaziou
Hello,

Bastien b...@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: [O] [RFC] Move ox-koma-letter into core?

2014-02-07 Thread Nicolas Goaziou
Bastien b...@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: [O] [RFC] Move ox-koma-letter into core?

2014-02-07 Thread Rasmus
Nicolas Goaziou n.goaz...@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: [O] [RFC] Move ox-koma-letter into core?

2014-02-07 Thread Thomas S. Dye
Aloha all,

Nicolas Goaziou n.goaz...@gmail.com writes:

 Bastien b...@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: [O] [RFC] Move ox-koma-letter into core?

2014-01-29 Thread Bastien
Hi Nicolas,

Nicolas Goaziou n.goaz...@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: [O] [RFC] Move ox-koma-letter into core?

2014-01-29 Thread Nicolas Goaziou
Hello,

Bastien b...@gnu.org writes:

 Bastien b...@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: [O] [RFC] Move ox-koma-letter into core?

2014-01-27 Thread Bastien
Hi all,

Bastien b...@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: [O] [RFC] Move ox-koma-letter into core?

2014-01-21 Thread 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: [O] [RFC] Move ox-koma-letter into core?

2014-01-21 Thread Bastien
Thanks for sharing your thoughts on this and clarifying the
possibilities.

Eric Schulte schulte.e...@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: [O] [RFC] Move ox-koma-letter into core?

2014-01-21 Thread Bastien
Hi Nick,

Nick Dokos ndo...@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: [O] [RFC] Move ox-koma-letter into core?

2014-01-21 Thread Nick Dokos
Bastien b...@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: [O] [RFC] Move ox-koma-letter into core?

2014-01-21 Thread 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: [O] [RFC] Move ox-koma-letter into core?

2014-01-21 Thread 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 lookfeel 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: [O] [RFC] Move ox-koma-letter into core?

2014-01-21 Thread Bastien
Achim Gratz strom...@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: [O] [RFC] Move ox-koma-letter into core?

2014-01-21 Thread Bastien
Achim Gratz strom...@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: [O] [RFC] Move ox-koma-letter into core?

2014-01-20 Thread 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: [O] [RFC] Move ox-koma-letter into core?

2014-01-20 Thread Bastien
Achim Gratz strom...@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: [O] [RFC] Move ox-koma-letter into core?

2014-01-20 Thread Achim Gratz
Bastien writes:
 Achim Gratz strom...@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: [O] [RFC] Move ox-koma-letter into core?

2014-01-20 Thread Bastien
Achim Gratz strom...@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: [O] [RFC] Move ox-koma-letter into core?

2014-01-20 Thread Rasmus
Bastien b...@gnu.org writes:

 Achim Gratz strom...@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: [O] [RFC] Move ox-koma-letter into core?

2014-01-20 Thread 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: [O] [RFC] Move ox-koma-letter into core?

2014-01-19 Thread Bastien
Carsten Dominik carsten.domi...@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: [O] [RFC] Move ox-koma-letter into core?

2014-01-19 Thread 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: [O] [RFC] Move ox-koma-letter into core?

2014-01-19 Thread Bastien
Achim Gratz strom...@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: [O] [RFC] Move ox-koma-letter into core?

2014-01-18 Thread Rasmus
Hi Nicolas,

Nicolas Goaziou n.goaz...@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: [O] [RFC] Move ox-koma-letter into core?

2014-01-18 Thread Carsten Dominik

On 18 Jan 2014, at 00:08, Nicolas Goaziou n.goaz...@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: [O] [RFC] Move ox-koma-letter into core?

2014-01-18 Thread Alan Schmitt
Nicolas Goaziou n.goaz...@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