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.,
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
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
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
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
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,
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
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:
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
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
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
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
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
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
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
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
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
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.
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)
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
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
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,
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
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
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
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
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
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
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
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
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
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
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:
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.
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
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
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:
37 matches
Mail list logo
