So basically everyone wants nREPL to be a "regular" project, and subject to and beneficiary of the same expectations as 99.9% of all of the other OSS projects we all interact with daily. How does that happen?
The only routes AFAICT are:
In either case, this "new" nREPL project's artifacts would end up being distributed under a different maven groupId (`com.cemerick`, if I'm to continue deploying, etc). The clojure-contrib nREPL project remain, and any releases that are done from it after the fork/reboot would continue to be under the `org.clojure` coordinates. Downstream projects need to choose whether or not to change dependencies; I'd expect the vast majority of future motion to gravitate to the reboot, but that's just speculation at this point.
I would like to hear here (no more private mails, please! :-) from any nREPL users, contributors, etc. As much as possible, I would like not to debate/re-litigate the merits of contrib and its process here; let's focus on what steps will yield the best outcome for nREPL and its stakeholders.
Thanks!
- Chas
What happens to a codebase that is subject to a CA that is
forked elsewhere? Are future contributions subject to that CA? I assume
not, but IANAL.
Does the "Copyright (c) Rich Hickey" banner that's
supposed to be on all files stay there permanently?
Pretty sure, but IANAL.
If all of the nontrivial contributors to the project decide they
want to change the license later, do we also need to obtain Rich's
assent?
(Parenthetically, it strikes me as very strange for a project to have a
copyright assignment to an individual that hasn't lodged any commits, at
least insofar as the project gone "solo". It's interesting that I don't
have that intuition if the assignee is an org like Apache or whatever, a
discrepancy that I'll have to think on.)
If all of the nontrivial contributors to the project decide they
want to change the license later, do we also need to obtain Rich's
assent?
This has nothing to do with Rich or the contributors. The project is available as open source under a license and you may only modify and distribute the code under the terms of the license. In this case, EPL requires that derivative code be released under EPL afaik.
(Parenthetically, it strikes me as very strange for a project to have a
copyright assignment to an individual that hasn't lodged any commits, at
least insofar as the project gone "solo". It's interesting that I don't
have that intuition if the assignee is an org like Apache or whatever, a
discrepancy that I'll have to think on.)
Afaik, this is not at all strange and is (legally) the exact same thing. Note that the copyright assignment in the Clojure Contributor Agreement is a *joint* copyright ownership. While rights are granted to Rich, they are also fully retained by the original author, which may imply that a "reboot" could include your original work and make derivatives of it without being pursuant to whatever the contrib version is doing. That would not automatically to other authors changes, but presumably they could make the same determination. Again, this is not legal advice, and this may not be correct - please read the CA and pursue better advice to make that judgement.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to a topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/6SX7q39lK90/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.
Of course, my aim would be to gather as much consensus as possible around a single nREPL vector; this thread is the first effort in service of that, with presumably much more ahead. An obvious move for example would be to shim out the legacy namespaces until a major version number change, so that migrating would involve only swapping some project.clj/pom.xml coordinates....where things go from there would be as much up to the community as anything else.
- Chas
On 7/18/2017 17:30, Phil Hagelberg wrote:
Thanks for continuing to maintain this lib, Chas; I'm glad to see this move to make it more accessible to potential contributors.--
I believe the original choice of the EPL was made specifically to support this kind of scenario. Personally I see a reboot as being a lot of effort for little gain, but then again it's neither my effort going into it nor my gain coming out of it. Besides, everyone's doing reboots these days.
I do suspect that a reboot will lead to a longer transition time in which both org.clojure/tools.nrepl and com.cemerick/nrepl are in active use by greenfield projects, so perhaps if you do a reboot you could cut an 0.2.12 release under the new group-id which has a stable known-good version and then do the reboot under a 1.x series or something. This might help alleviate the concerns raised by Colin more quickly.
-Phil
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to a topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/6SX7q39lK90/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojure+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
I'm not too familiar with the way contribs are managed, isn't tools.nrepl repo in github? Wouldn't the only step to contribute be to sign the CA and send a pull request of your changes?
I'm not too familiar with the way contribs are managed, isn't tools.nrepl repo in github? Wouldn't the only step to contribute be to sign the CA and send a pull request of your changes?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
On 7/18/2017 14:40, Alex Miller wrote:
If all of the nontrivial contributors to the project decide they
want to change the license later, do we also need to obtain Rich's
assent?
This has nothing to do with Rich or the contributors. The project is available as open source under a license and you may only modify and distribute the code under the terms of the license. In this case, EPL requires that derivative code be released under EPL afaik.
My point was that the license under which code is distributed can be changed, with the assent of all contributors.
I understand it's hard to estimate how many people were discouraged by this. Maybe it should be part of the Clojure survey nexr time.
Were you ever discouraged to contribute to a Contrib lib because of Jira?
Were you ever discouraged to contribute to a Contrib lib because of the CA?
I feel like without more data into these, it's only speculative that changes to nRepl would result in more active contributions from the community.
At the risk of being unpopular… 😊
I think there are quite a few people who _say_ that it’s an obstacle to their contributing to Clojure or to a Contrib library but in reality they wouldn’t actually contribute anyway, so it becomes an excuse.
For example, I’ve seen many people over the years complain about needing to sign a CA and submit a patch in order to update the documentation that is part of a project. Years ago, I moved all the documentation for clojure.java.jdbc off to clojure-doc.org where anyone can create issues and submit PRs because it’s “just” a GitHub project. Despite removing all the supposed “barriers to entry”, there have been almost zero community contributions of any sort to that documentation (with one recent exception: huge thank you to ehashman for some great work submitted recently!).
A lot of big, well-known FOSS projects require a signed CA and have very specific contributing processes. Either folks will contribute or they won’t. I find it hard to believe that nREPL will suddenly get a stream of contributions that it wouldn’t get if it continues as a Contrib project. Hundreds of people have signed CAs on file – there’s a good pool of people who could, easily, contribute to nREPL already.
Forking, renaming, and rebooting a fundamental bedrock project like nREPL could be very risky, and could cause a lot of pain/churn for a lot of Clojure users out there.
(or of course you could all prove me wrong and it might be a painless transition and nREPL might flourish in ways none of us could possibly have imagined so far…)
Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
On 20 Jul 2017, at 17:14, Sean Corfield wrote:
A lot of big, well-known FOSS projects require a signed CA and have very specific contributing processes. Either folks will contribute or they won’t. I find it hard to believe that nREPL will suddenly get a stream of contributions that it wouldn’t get if it continues as a Contrib project. Hundreds of people have signed CAs on file – there’s a good pool of people who could, easily, contribute to nREPL already.
One thing I like about using the Gerrit code review tool ( and GerritHub, for Github based projects ) is the ability add in a CA verification on a submitted patch, before pushing users just need to log in to the website and sign a webform before pushing, nice and clean and no fuss.
Google based OSS projects on Github have a similar bot system, when you make a PR if you ( or more, the email address in the commits ) haven't signed a CA a comment is added, with instructions on how to use a webform to register, you then comment on the ticket with "I've signed it!" and the bot re-verifies, and all is golden.
Very low barrier - my only issue with the Clojure CA was ( at least when I submitted ) that it had to be printed/faxed and sent off, and took ages to get approved. I have no idea what the process is these days?
Mark
"The ease with which a change can be implemented has no relevance at all to whether it is the right change for the (Java) Platform for all time." — Mark Reinhold.
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt
At the risk of being unpopular… 😊
I think there are quite a few people who _say_ that it’s an obstacle to their contributing to Clojure or to a Contrib library but in reality they wouldn’t actually contribute anyway, so it becomes an excuse.
For example, I’ve seen many people over the years complain about needing to sign a CA and submit a patch in order to update the documentation that is part of a project. Years ago, I moved all the documentation for clojure.java.jdbc off to clojure-doc.org where anyone can create issues and submit PRs because it’s “just” a GitHub project. Despite removing all the supposed “barriers to entry”, there have been almost zero community contributions of any sort to that documentation (with one recent exception: huge thank you to ehashman for some great work submitted recently!).
A lot of big, well-known FOSS projects require a signed CA and have very specific contributing processes. Either folks will contribute or they won’t. I find it hard to believe that nREPL will suddenly get a stream of contributions that it wouldn’t get if it continues as a Contrib project. Hundreds of people have signed CAs on file – there’s a good pool of people who could, easily, contribute to nREPL already.
Forking, renaming, and rebooting a fundamental bedrock project like nREPL could be very risky, and could cause a lot of pain/churn for a lot of Clojure users out there.
(or of course you could all prove me wrong and it might be a painless transition and nREPL might flourish in ways none of us could possibly have imagined so far…)
Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
So do we have any idea of contributions are not made because of the CA or Jira?
I understand it's hard to estimate how many people were discouraged by this. Maybe it should be part of the Clojure survey nexr time.
Were you ever discouraged to contribute to a Contrib lib because of Jira?
Were you ever discouraged to contribute to a Contrib lib because of the CA?
I feel like without more data into these, it's only speculative that changes to nRepl would result in more active contributions from the community.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
--
I'd much rather see nREPL stay within contrib and the renewed effort, that you propose, to go into ironing out kinks in the contrib process
--
Are you saying the contrib process is deliberatly made to be difficult for the community to contribute to it?
If so, maybe if it had more obvious tenets, I find its difficult as a user to understand what the contribs are for, who maintains them, what their status are, and how they differ to the standards library, or other community projects.
I can't contribute to OSS, because of my current employment, but as a non contributing Clojure user, I've always wondered how much I should rely on contribs, some of them seem quasi-abandonned, yet they appear more official, and it makes it hard for me to decide if I want to take a dependency on them or not.
In a way, an active project gives me more trust, and if taking nRepl out of contrib makes it more active, that's a good thing. Unless contrib libs come with any official support guarantees, or some form of stronger commitments?
Are you saying the contrib process is deliberatly made to be difficult for the community to contribute to it?