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: > > 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 > > On 7/18/2017 13:19, Dan Larkin wrote: > > 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? > > > > > >> On Jul 18, 2017, at 05:48, Chas Emerick <ch...@cemerick.com > <javascript:>> wrote: > >> > >> 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: > >> • nREPL is an essential bit of infrastructure in Clojure > tooling > >> • On balance, I have neglected the project in recent years, to > the detriment of all of the users of the aforementioned tooling. > >> • 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) > >> • 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: > >> > >> • 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. > >> • 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 > >> > >> -- > >> 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 > <javascript:> > >> 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 <javascript:> > >> 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 <javascript:>. > >> 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 clojure@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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
