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 <c...@cemerick.com> 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 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. -- 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.
