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 organization
I added a beginner om-next tutorial here:
https://github.com/ftravers/missing-links
Feedback welcome.
Thanks,
Fenton
--
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
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 wrote:
>
> Hi all,
>
> I've been approached many, many times over the years (and more frequently
> sin
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.
For
And I helped! ... cue shake n bake commercial
> On Jul 18, 2017, at 11:02, 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 b
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
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
p
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,
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 sou
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 m
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,
si
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
12 matches
Mail list logo
