Migrating nREPL out of Clojure Contrib

[Chas Emerick]

Hi all,

I've been approached many, many times over the years (and more frequently since the development and inclusion of socket-repl) about the potential of moving nREPL[1] out of clojure contrib…either back to its original location[2], or under one of the various Clojure community organizations. I've generally demurred or ghosted on these suggestions, sometimes out of a lack of time/attention, and often out of just not wanting to stir the pot. The pace of them has quickened somewhat lately though, and I'd like to put the whole topic to bed and hopefully get the project to a better footing in the process.

First, to stipulate a few things:

1. nREPL is an essential bit of infrastructure in Clojure tooling
2. On balance, I have neglected the project in recent years, to the detriment of all of the users of the aforementioned tooling.
3. On balance, contributors and potential contributors have been less involved (or turned away entirely) because of the well-known friction that comes with the contrib process and requirements. (tbh, this is a factor in #2, though not the majority)
4. No one (least of all me) would object to nREPL having its contribution process managed through github or gitlab.

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:

1. to fork back elsewhere, which would require keeping the EPL license and copyright assignment of the current codebase. Literally anyone can do this at any time, without any coordination with anyone else.
   
2. for me to reboot the project. This would not be difficult given I "own" the vast majority of the project's commits. This would allow for the elimination of the copyright assignment, and potentially a different license (I'm partial to MPLv2, but we'll see). If this route is taken, we could set up a project issue where the other contributors of nontrivial patches could agree (or not) to the reconstitution of their code w/o the copyright assignment, etc.

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

[1] https://github.com/clojure/tools.nrepl/
[2] https://github.com/cemerick/nrepl

[Dan Larkin]

Hi Chas!

This is great news, I'm glad to hear development will resume. What's the downside to just forking? aka why bother rebooting from scratch?

> --
> 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 the Google Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Chas Emerick]

To be clear ("well ACTUALLY" :-P), development hasn't ceased, just
slowed to a trickle. (There are commits this year, so there?) Part of
that is nREPL being intentionally a slow-moving bit of bedrock for other
people to build on. That's not to discount my original stipulations (1)
and (2) ofc.

Forking is obviously easiest. Like I said, anyone can do that anytime.

The benefit to rebooting is to shake off whatever responsibilities or
constraints are associated with the (eventually prior) copyright
assignment. 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? I have no idea. Do I want to maintain explanations of the right
answers to these kinds of questions for a (fork of a) project that's no
longer within contrib? Most definitely not.

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

That was a good question! Answering helped clarify things for me:
specifically, if I'm going to maintain the project outside of contrib, I
will reboot it as previously described.

Thanks,

- Chas

[Dan Larkin]

And I helped! ... cue shake n bake commercial

[Alex Miller]

On Tuesday, July 18, 2017 at 1:03:09 PM UTC-5, Chas Emerick wrote:

 

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.

(Blanket IANAL)

No.

 

Does the "Copyright (c) Rich Hickey" banner that's
supposed to be on all files stay there permanently?  

Pretty sure, but IANAL.

The existing code retains its copyright and must be labeled as such. New code should be labeled appropriately.

 

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.

[Colin Jones]

FWIW, as someone who's used and made small contributions to nREPL, I'm fine with any of the options (leaving it in contrib, forking, rebooting). My lack of contributions hasn't been due to process around nREPL (my lack of activity on REPLy [1] can validate that) - more around a lack of direct pain points to address.

One initial reaction to these options is that it will become harder to manage versioning & compatibility for nREPL servers/clients if (a) this leaves contrib [either by forking or rebooting], (b) development continues on both, ultimately including separate feature sets, and (c) the community doesn't 100% settle on one of them. We already have versioning to worry about, it'll just be an additional axis (maven groupId), so not a blocker, just what I'd call a mild concern.

For my downstream use in REPLy (which is `lein repl` and `boot repl` under the hood), I've got some long-term ideas (influenced by a great talk Stu Halloway did last month) about breaking things apart to make it possible to opt in (and out) of jline, nrepl, socket-repl, etc. dependencies. That kind of thing could allow integration of either fork, but I haven't thought through all the pieces and implications. And at any rate, I don't see myself tackling those anytime soon, but would be happy to have help :)

Just some random thoughts, but generally I don't have a strong inclination towards / away from any of the options, and would be fine to do what the project needs w/ regard to my contributions.

- Colin

[1] https://github.com/trptcolin/reply

On Tuesday, July 18, 2017 at 1:03:09 PM UTC-5, Chas Emerick wrote:

[Phil Hagelberg]

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

[Chas Emerick]

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. (One of the practical rationales of CAs is that the assignee then has ultimate latitude to change the license, without having to clear that administrative hurdle.) If in some future where project X is forked to be independent of an entity that previously was a (yes, joint) copyright assignee, do the project leads for X have to obtain that entity's agreement in order to change the license? Questions about relicensing are sort of comical IMO in the context of a project the size and importance of nREPL, but they and everything else related to licensing questions come up on a regular basis in the context of having a CA, and the answers end up mattering to contributors.

 

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

Yes, it's legally the same thing, but I don't think it'd be controversial to say that assigning copyright to an individual has very different practical and qualitative consequences compared to an organization like Apache or FSF or Linux Foundation. Reams more could be written about CAs and foundations (or not) and all that, but this is already treading too far OT. :-)

FWIW, I had intended my legal questions previously to be rhetorical (though I appreciate the qualified answers that confirmed my intuitions); I think the broader point is that, insofar as an independent project isn't going to benefit from being in contrib any longer, if it's possible, I see no reason to carry that legacy. For better or worse, the commit history of nREPL is such that a reboot is quite reasonable as you describe, i.e. taking my commits, re-forming a project, and applying all of the changes from other contributors that agree to come along. Any differential is going to be relatively trivial to straighten out.

(Sorry for any duplicate mails. I'm out of practice w.r.t. ML reply-all habits!)

- Chas

[Chas Emerick]

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

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

[Colin Fleming]

I don't have much more to add than what others have written - I don't have very strong feelings about this, but it seems worth fixing if the contrib process is a significant barrier to contribution. And if that happens, I agree with Chas that it seems worth taking the time to reboot it properly, since having the CA in the project's history will probably confuse potential contributors who care about that sort of thing.

In general, I've never had the need to submit patches for nREPL since it's been stable since I started using it seriously. That's only for Clojure though, I believe there's some serious work that could be done on the ClojureScript side and IIRC that was a source of some frustration for some users a while back. I'd be very happy to see that progressing!

There are also potential issues with API compatibility going forward, but I don't see those as particularly more difficult than if nREPL continues to evolve under the contrib umbrella. I also suspect that there's probably not too much risk of the community fragmenting - you'd only have to convince less than half a dozen nREPL clients to switch and you'd get essentially the whole community moving, I expect. As long as the wire protocol doesn't change during that transition I don't see why that would be too painful.

Cheers,

Colin

On 19 July 2017 at 12:09, Chas Emerick <ch...@cemerick.com> wrote:

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

clojure+unsubscribe@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+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

clojure+unsubscribe@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 the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.

[Didier]

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?

[Andy Fingerhut]

Contribs are on github, but none of them accept pull requests.  All of them use JIRA for tickets, listed here: https://dev.clojure.org/jira/secure/BrowseProjects.jspa#all

Some background on the contribution process: https://dev.clojure.org/display/community/Contributing+FAQ

Andy

On Tue, Jul 18, 2017 at 11:10 PM, Didier <did...@gmail.com> wrote:

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?

[Bozhidar Batsov]

Contrib projects do not accept pull requests. They accept only patches submitted via JIRA. 

On Wed, Jul 19, 2017 at 09:11 Didier <did...@gmail.com> wrote:

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

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 the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.

[Rick Moynihan]

On 19 July 2017 at 01:03, Chas Emerick <ch...@cemerick.com> wrote:

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.

My layman understanding of licensing/CA's is that the licence/terms of the project could theoretically be changed with either:

- The assent of all contributors except Rich.  If as you say Rich has no commits in the code, then providing everyone else who owns copyrights to their contributions on the code agrees to the new licence/change then the fork could be relicensed, and Rich's blessing would not I think be needed; as everyone else together will hold copyrights on the code also.  I'd imagine in this case even the (c) attribution to Rich could be removed if everyone agreed.

- The assent of just Rich.  As Rich is the only person who owns copyrights to every contribution, he could singlehandedly relicense a fork as he wishes.

Hypothetically either one or both of these could happen in a fork.

Obviously this puts Rich in a privileged position whilst the project remains in contrib behind the CA process.  If the project forked to github without a C/A Rich couldn't stop it (as it's also been licenced under the EPL).  However future contributions on this fork would not be (c) to Rich so relicensing might be even harder; as you'd be forced to get the assent of everyone else.

The only other thing I can think of that's theorerically relevant is that contibutors under the CA promise not to sue Rich for him breaching any patents etc, but I don't think the CA grants that privilege back to the contribtors.

R.

[Mikera]

Why is the EPL a problem? It is pretty much the standard in the Clojure ecosystem, even for non-core libraries. As long as you keep future contributions under the EPL, surely you can just fork and drop the CLA requirement?

FWIW, I've been using nREPL for a "Clojure-like" experimental language and it has been awesome so far (see https://github.com/mikera/enchant). Thanks for the great work!

[Didier]

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.

[Sean Corfield]

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

[Mark Derricutt]

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

[Bozhidar Batsov]

On 20 July 2017 at 08:14, Sean Corfield <se...@corfield.org> wrote:

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

I think few people can doubt my contributions to OSS projects, but I value my time too much to waste it on JIRA and updating patches like crazy there. Raising the barrier to entry to basic projects like nREPL and clojure.java.jdbc seems pointless to me. It might make sense for Clojure, but it certainly doesn't make much sense for anything else.

Giving a documentation example is unfair - how many developers fond of writing documentation do you know? Most of my bigger OSS projects are getting a ton of contributions from all sorts of people. 

 

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.

Let's be honest - Chas is basically the only nREPL dev, so it seems to me that all we need to have a painless transition is his blessing of a fork/reboot. The pain would be mostly updating deps in projects like lein and boot. CIDER is one of the projects with biggest commitment to nREPL (and we've been behind many bugfixes and small improvements in recent years) and we'd support a fork/reboot 100%.  

 

(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

 

From: Didier
Sent: Wednesday, July 19, 2017 9:43 PM
To: Clojure
Subject: Re: Migrating nREPL out of Clojure Contrib

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

clojure+unsubscribe@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 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

clojure+unsubscribe@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 the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.

[Bozhidar Batsov]

My vote is for a project reboot spearheaded by you. I doubt people would have objections to the relicensing of the project and I promise to help as much as I can if the project gets "freed" from the shackles of contrib.

I do thing it might make sense for the project to be housed under a nREPL org on github, which can also house related important middleware and potentially client libraries for different languages.  

Thanks!

- Chas

[1] https://github.com/clojure/tools.nrepl/
[2] https://github.com/cemerick/nrepl

--

[Meikel Brandmeyer (kotarak)]

Hi Chas,

I have no hard feelings about the hosting or organisation of the nrepl project. If you feel that a different organisation would improve things, then go for it.

In contrast to your invest, I haven't much contributed besides problems and complexity. ;-P If you need anything regarding my contributions to sort out license and/or CA issues, just ping me.

Meikel

[Phillip Lord]

Alex Miller <al...@puredanger.com> writes:

> On Tuesday, July 18, 2017 at 1:03:09 PM UTC-5, Chas Emerick wrote:
>> (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.

Not really. The Apache foundation is a discrete legal entity, with a
declared constitution and legal obligations. Rich is a person; he could
sell the software to anyone. He could die, and then the ownership would
pass to someone.

*Who* owns the copyright is important in a copyright assignment
process. You are putting your trust in that person or organisation, and
whoever that person or organisation passes ownership to.

Phil

[Herwig Hochleitner]

2017-07-18 14:48 GMT+02:00 Chas Emerick <ch...@cemerick.com>:
> 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.

I only have a stake as a user (unfortunately), but FWIW, 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 (e.g. for one-off contributions, the assignment could go into the commit message, maybe?; also our atlassian versions could do with an update; also, it would be _really_ nice, if patches could be discussed/accepted on the [dev-] mailing list, LKML style)

I realize, that this is effectively asking Chas to roll the boulder up the hill, yet another time, but my reason is simple:
For infrastructure, free market principles don't easily apply: People generally fix roads instead of adding new ones in parallel to existing ones, and if there ever is an "infrastructurey" clojure library, it would be tools.nrepl. Also, like Sean Corfield, I have my reservations about the potential for contribution increases due to a reboot.
To me the risks of a reboot far outweigh the potential benefits.

That said, Chas and Bozhidar, as the largest stakeholders, both seem to be in favor of a reboot, hence I wouldn't veto it even if I could.

[Colin Fleming]

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

FWIW I don't think this is a realistic option, certainly not for anyone outside of Clojure core. The contrib process is in place because some want it that way - it's very deliberately by design and AFAICT unlikely to change. For projects where the maintainer for whatever reason doesn't want to use that process (I believe nREPL would be the first, but I don't know all the history) I think moving that project out of contrib is likely to mean the least amount of frustration.

--

[Didier]

> The contrib process is in place because some want it that way - it's very deliberately by design and AFAICT unlikely to change.

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?

[Colin Fleming]

Are you saying the contrib process is deliberatly made to be difficult for the community to contribute to it?

No, not at all, just that it's deliberately designed to be exactly the way it is, so dedicating a lot of time to trying to change that is likely to be frustrating and fruitless.

I agree about the confusion of a lot of the contrib projects, I'm often unsure if they're abandoned or just mature. I don't know if the expectation or the reality is that they should all be in a working state.

[Bozhidar Batsov]

So, what's the next step here? 

[Chas Emerick]

I have opened two issues on the original nREPL repo:

1. Describing the background and rationale for the work to be done:
https://github.com/cemerick/nREPL/issues/1

2. Enumerating the nREPL contributors to obtain explicit permission for
their commits to be distributed under the terms of EPL only (i.e. absent
the terms of the CA that governed their contribution to the tools.nrepl
project): https://github.com/cemerick/nREPL/issues/2

Once #2 is complete, then the list of tasks in #1 will be burned down.
We'll then have a 100% compatible nREPL release out the door with
different maven coordinates, etc., and those that are interested in
contributing will be able to do so straightforwardly.

Cheers,

- Chas

[Chas Emerick]

A final update:

https://github.com/cemerick/nREPL has been reconstituted as described
previously, and a release candidate has been deployed to maven central
with contents effectively identical to the latest tools.nrepl release
(only difference is an ipv6-related bugfix that was encountered in the
process of setting up travis ci).

This is all to say that things are underway! I'll stop posting updates
here, so if you're interested, you can continue to track
https://github.com/cemerick/nREPL/issues/1 for the final first release,
and the issue tracker on github is also now populated with things from
JIRA that will get burned down prior to a 1.0.0 release.

All the best,

- Chas

[Nick Mudge]

I am new to the clojure community. What does it mean to "reboot" the project?