Re: Migrating nREPL out of Clojure Contrib

[Nick Mudge]

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


On Friday, July 21, 2017 at 5:15:49 AM UTC-7, Herwig Hochleitner wrote:
>
> 2017-07-18 14:48 GMT+02:00 Chas Emerick  >:
> > 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.
>

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

Re: Migrating nREPL out of Clojure Contrib

[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

On 10/9/2017 14:59, Chas Emerick wrote:
> 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
>
> On 8/3/2017 00:36, Bozhidar Batsov wrote:
>> So, what's the next step here?
>


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

Re: Migrating nREPL out of Clojure Contrib

[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

On 8/3/2017 00:36, Bozhidar Batsov wrote:
> So, what's the next step here?


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

Re: Migrating nREPL out of Clojure Contrib

[Bozhidar Batsov]

So, what's the next step here?

On 23 July 2017 at 02:16, Colin Fleming  wrote:

> 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.
>
> On 23 July 2017 at 09:17, Didier  wrote:
>
>> > 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?
>>
>> --
>> 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.
>

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

Re: Migrating nREPL out of Clojure Contrib

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

On 23 July 2017 at 09:17, Didier  wrote:

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

Re: Migrating nREPL out of Clojure Contrib

[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?

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

Re: Migrating nREPL out of Clojure Contrib

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

On 22 July 2017 at 00:15, Herwig Hochleitner  wrote:

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

Re: Migrating nREPL out of Clojure Contrib

[Herwig Hochleitner]

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

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

Re: Migrating nREPL out of Clojure Contrib

[Phillip Lord]

Alex Miller  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

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

Re: Migrating nREPL out of Clojure Contrib

[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

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

Re: Migrating nREPL out of Clojure Contrib

[Bozhidar Batsov]

On 18 July 2017 at 15:48, Chas Emerick  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:
>
>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.
>

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

Re: Migrating nREPL out of Clojure Contrib

[Bozhidar Batsov]

On 20 July 2017 at 08:14, Sean Corfield <s...@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 <didi...@gmail.com>
> *Sent: *Wednesday, July 19, 2017 9:43 PM
> *To: *Clojure <clojure@googlegroups.com>
> *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 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...@googlegro

Re: Migrating nREPL out of Clojure Contrib

[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

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


signature.asc
Description: OpenPGP digital signature

RE: Migrating nREPL out of Clojure Contrib

[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

From: Didier<mailto:didi...@gmail.com>
Sent: Wednesday, July 19, 2017 9:43 PM
To: Clojure<mailto:clojure@googlegroups.com>
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 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.

Re: Migrating nREPL out of Clojure Contrib

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

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

Re: Migrating nREPL out of Clojure Contrib

[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!


On Tuesday, 18 July 2017 20:48:15 UTC+8, Chas Emerick 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:
>
>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
>

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

Re: Migrating nREPL out of Clojure Contrib

[Rick Moynihan]

On 19 July 2017 at 01:03, Chas Emerick  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.

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

Re: Migrating nREPL out of Clojure Contrib

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

Re: Migrating nREPL out of Clojure Contrib

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

Re: Migrating nREPL out of Clojure Contrib

[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?

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

Re: Migrating nREPL out of Clojure Contrib

[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  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
> coordinateswhere 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 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 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+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.
>

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

Re: Migrating nREPL out of Clojure Contrib

[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 coordinateswhere 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 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 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+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.

Re: Migrating nREPL out of Clojure Contrib

[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

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

Re: Migrating nREPL out of Clojure Contrib

[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

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

Re: Migrating nREPL out of Clojure Contrib

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

Re: Migrating nREPL out of Clojure Contrib

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

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

Re: Migrating nREPL out of Clojure Contrib

[Dan Larkin]

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

Re: Migrating nREPL out of Clojure Contrib

[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

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

Re: Migrating nREPL out of Clojure Contrib

[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?


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