Requesting a new GH repository for CrossDC modules

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Requesting a new GH repository for CrossDC modules

Anshum Gupta
Hi everyone,

Inline with my earlier email, I'll be requesting a new repository to host the cross-dc work. Please let me know if you have any questions or concerns.

Repository name: solr-crossdc
Generated name: lucene-solr-crossdc.git (that's auto-generated, so can't remove the TLP prefix)
Commit notification list: [hidden email] (I think it makes sense for these commit notifications to go to a new list, but I'm open to reusing the old one)
GitHub notification list: [hidden email]

I'll be submitting a request for the same later in the day today if there are no concerns.

--
Anshum Gupta
Reply | Threaded
Open this post in threaded view
|

Re: Requesting a new GH repository for CrossDC modules

Ishan Chattopadhyaya
-1 on this. Without finalizing on the shape of how the solution will look like, I don't think we should start a repository: it would be bad if we have to abandon the repository of our approach changes (say we want to keep it tightly integrated inside Solr).

On Thu, 7 Jan, 2021, 11:45 pm Anshum Gupta, <[hidden email]> wrote:
Hi everyone,

Inline with my earlier email, I'll be requesting a new repository to host the cross-dc work. Please let me know if you have any questions or concerns.

Repository name: solr-crossdc
Generated name: lucene-solr-crossdc.git (that's auto-generated, so can't remove the TLP prefix)
Commit notification list: [hidden email] (I think it makes sense for these commit notifications to go to a new list, but I'm open to reusing the old one)
GitHub notification list: [hidden email]

I'll be submitting a request for the same later in the day today if there are no concerns.

--
Anshum Gupta
Reply | Threaded
Open this post in threaded view
|

Re: Requesting a new GH repository for CrossDC modules

Anshum Gupta
I understand your concern, but this is the placeholder for where the code would be, not what the code would look like. 

Considering we agreed to do this in a repository outside of the core, I believe this is a good place to start. The idea that the release cadence for the cross-dc effort should be different from that of core is an argument in favor of this approach, but I'm happy to talk more about it. 
I just thought that based on the original email, folks were on-board with the idea of this being outside of core Solr artifact/release.

On Thu, Jan 7, 2021 at 11:06 AM Ishan Chattopadhyaya <[hidden email]> wrote:
-1 on this. Without finalizing on the shape of how the solution will look like, I don't think we should start a repository: it would be bad if we have to abandon the repository of our approach changes (say we want to keep it tightly integrated inside Solr).

On Thu, 7 Jan, 2021, 11:45 pm Anshum Gupta, <[hidden email]> wrote:
Hi everyone,

Inline with my earlier email, I'll be requesting a new repository to host the cross-dc work. Please let me know if you have any questions or concerns.

Repository name: solr-crossdc
Generated name: lucene-solr-crossdc.git (that's auto-generated, so can't remove the TLP prefix)
Commit notification list: [hidden email] (I think it makes sense for these commit notifications to go to a new list, but I'm open to reusing the old one)
GitHub notification list: [hidden email]

I'll be submitting a request for the same later in the day today if there are no concerns.

--
Anshum Gupta


--
Anshum Gupta
Reply | Threaded
Open this post in threaded view
|

Re: Requesting a new GH repository for CrossDC modules

Mike Drob-3
I'm not sure where I sit on this, going to start typing things and then hopefully I'll reach a conclusion by the end.

This definitely needs to be outside of the core solr repo so that it can be versioned and released independently. And I disagree with Ishan about the consequence of abandoning the repository - if we realize that it's a bad direction then we can pivot, but we shouldn't let a fear of the unknown stop us from doing it in the first place.

However, if all we need right now is a place to commit code that is WIP, then what we really want is a sandbox to play with, and not necessarily a strongly directed repo. Lucene has a sandbox in the main code. We could similarly start this under Solr contrib and move it out before an actual release of 9x happens. Or maybe we start with a [lucene-]solr-sandbox repository that we can throw all sorts of stuff into and then when components are mature enough they get to graduate into their own repo?

Mike

On Thu, Jan 7, 2021 at 2:32 PM Anshum Gupta <[hidden email]> wrote:
I understand your concern, but this is the placeholder for where the code would be, not what the code would look like. 

Considering we agreed to do this in a repository outside of the core, I believe this is a good place to start. The idea that the release cadence for the cross-dc effort should be different from that of core is an argument in favor of this approach, but I'm happy to talk more about it. 
I just thought that based on the original email, folks were on-board with the idea of this being outside of core Solr artifact/release.

On Thu, Jan 7, 2021 at 11:06 AM Ishan Chattopadhyaya <[hidden email]> wrote:
-1 on this. Without finalizing on the shape of how the solution will look like, I don't think we should start a repository: it would be bad if we have to abandon the repository of our approach changes (say we want to keep it tightly integrated inside Solr).

On Thu, 7 Jan, 2021, 11:45 pm Anshum Gupta, <[hidden email]> wrote:
Hi everyone,

Inline with my earlier email, I'll be requesting a new repository to host the cross-dc work. Please let me know if you have any questions or concerns.

Repository name: solr-crossdc
Generated name: lucene-solr-crossdc.git (that's auto-generated, so can't remove the TLP prefix)
Commit notification list: [hidden email] (I think it makes sense for these commit notifications to go to a new list, but I'm open to reusing the old one)
GitHub notification list: [hidden email]

I'll be submitting a request for the same later in the day today if there are no concerns.

--
Anshum Gupta


--
Anshum Gupta
Reply | Threaded
Open this post in threaded view
|

Re: Requesting a new GH repository for CrossDC modules

Anshum Gupta
Thanks for the feedback, Mike.

I like the idea of the sandbox, but that might be restricting when we want to work on more than one repos.

I'm not sure if that would happen in the near future, but as we can always discard the repo and it doesn't really come at a cost, I don't see a problem with having a repo created for this specific reason.

On Thu, Jan 7, 2021 at 12:45 PM Mike Drob <[hidden email]> wrote:
I'm not sure where I sit on this, going to start typing things and then hopefully I'll reach a conclusion by the end.

This definitely needs to be outside of the core solr repo so that it can be versioned and released independently. And I disagree with Ishan about the consequence of abandoning the repository - if we realize that it's a bad direction then we can pivot, but we shouldn't let a fear of the unknown stop us from doing it in the first place.

However, if all we need right now is a place to commit code that is WIP, then what we really want is a sandbox to play with, and not necessarily a strongly directed repo. Lucene has a sandbox in the main code. We could similarly start this under Solr contrib and move it out before an actual release of 9x happens. Or maybe we start with a [lucene-]solr-sandbox repository that we can throw all sorts of stuff into and then when components are mature enough they get to graduate into their own repo?

Mike

On Thu, Jan 7, 2021 at 2:32 PM Anshum Gupta <[hidden email]> wrote:
I understand your concern, but this is the placeholder for where the code would be, not what the code would look like. 

Considering we agreed to do this in a repository outside of the core, I believe this is a good place to start. The idea that the release cadence for the cross-dc effort should be different from that of core is an argument in favor of this approach, but I'm happy to talk more about it. 
I just thought that based on the original email, folks were on-board with the idea of this being outside of core Solr artifact/release.

On Thu, Jan 7, 2021 at 11:06 AM Ishan Chattopadhyaya <[hidden email]> wrote:
-1 on this. Without finalizing on the shape of how the solution will look like, I don't think we should start a repository: it would be bad if we have to abandon the repository of our approach changes (say we want to keep it tightly integrated inside Solr).

On Thu, 7 Jan, 2021, 11:45 pm Anshum Gupta, <[hidden email]> wrote:
Hi everyone,

Inline with my earlier email, I'll be requesting a new repository to host the cross-dc work. Please let me know if you have any questions or concerns.

Repository name: solr-crossdc
Generated name: lucene-solr-crossdc.git (that's auto-generated, so can't remove the TLP prefix)
Commit notification list: [hidden email] (I think it makes sense for these commit notifications to go to a new list, but I'm open to reusing the old one)
GitHub notification list: [hidden email]

I'll be submitting a request for the same later in the day today if there are no concerns.

--
Anshum Gupta


--
Anshum Gupta


--
Anshum Gupta
Reply | Threaded
Open this post in threaded view
|

Re: Requesting a new GH repository for CrossDC modules

Ishan Chattopadhyaya
If all we need now is a place to commit a PoC for now (and something like sandbox repo or contribs won't suffice), why can't we have a separate repository in GitHub outside Apache and merge into an Apache repository only once the code takes reasonable shape?

On Fri, 8 Jan, 2021, 2:31 am Anshum Gupta, <[hidden email]> wrote:
Thanks for the feedback, Mike.

I like the idea of the sandbox, but that might be restricting when we want to work on more than one repos.

I'm not sure if that would happen in the near future, but as we can always discard the repo and it doesn't really come at a cost, I don't see a problem with having a repo created for this specific reason.

On Thu, Jan 7, 2021 at 12:45 PM Mike Drob <[hidden email]> wrote:
I'm not sure where I sit on this, going to start typing things and then hopefully I'll reach a conclusion by the end.

This definitely needs to be outside of the core solr repo so that it can be versioned and released independently. And I disagree with Ishan about the consequence of abandoning the repository - if we realize that it's a bad direction then we can pivot, but we shouldn't let a fear of the unknown stop us from doing it in the first place.

However, if all we need right now is a place to commit code that is WIP, then what we really want is a sandbox to play with, and not necessarily a strongly directed repo. Lucene has a sandbox in the main code. We could similarly start this under Solr contrib and move it out before an actual release of 9x happens. Or maybe we start with a [lucene-]solr-sandbox repository that we can throw all sorts of stuff into and then when components are mature enough they get to graduate into their own repo?

Mike

On Thu, Jan 7, 2021 at 2:32 PM Anshum Gupta <[hidden email]> wrote:
I understand your concern, but this is the placeholder for where the code would be, not what the code would look like. 

Considering we agreed to do this in a repository outside of the core, I believe this is a good place to start. The idea that the release cadence for the cross-dc effort should be different from that of core is an argument in favor of this approach, but I'm happy to talk more about it. 
I just thought that based on the original email, folks were on-board with the idea of this being outside of core Solr artifact/release.

On Thu, Jan 7, 2021 at 11:06 AM Ishan Chattopadhyaya <[hidden email]> wrote:
-1 on this. Without finalizing on the shape of how the solution will look like, I don't think we should start a repository: it would be bad if we have to abandon the repository of our approach changes (say we want to keep it tightly integrated inside Solr).

On Thu, 7 Jan, 2021, 11:45 pm Anshum Gupta, <[hidden email]> wrote:
Hi everyone,

Inline with my earlier email, I'll be requesting a new repository to host the cross-dc work. Please let me know if you have any questions or concerns.

Repository name: solr-crossdc
Generated name: lucene-solr-crossdc.git (that's auto-generated, so can't remove the TLP prefix)
Commit notification list: [hidden email] (I think it makes sense for these commit notifications to go to a new list, but I'm open to reusing the old one)
GitHub notification list: [hidden email]

I'll be submitting a request for the same later in the day today if there are no concerns.

--
Anshum Gupta


--
Anshum Gupta


--
Anshum Gupta
Reply | Threaded
Open this post in threaded view
|

Re: Requesting a new GH repository for CrossDC modules

Mike Drob-3
An external repository probably ends up requiring a software grant? I know there is a material difference between code originating externally and code originating within the umbrella of the ASF in terms of IP, copyright, or other legal status. 


On Thu, Jan 7, 2021 at 8:11 PM Ishan Chattopadhyaya <[hidden email]> wrote:
If all we need now is a place to commit a PoC for now (and something like sandbox repo or contribs won't suffice), why can't we have a separate repository in GitHub outside Apache and merge into an Apache repository only once the code takes reasonable shape?

On Fri, 8 Jan, 2021, 2:31 am Anshum Gupta, <[hidden email]> wrote:
Thanks for the feedback, Mike.

I like the idea of the sandbox, but that might be restricting when we want to work on more than one repos.

I'm not sure if that would happen in the near future, but as we can always discard the repo and it doesn't really come at a cost, I don't see a problem with having a repo created for this specific reason.

On Thu, Jan 7, 2021 at 12:45 PM Mike Drob <[hidden email]> wrote:
I'm not sure where I sit on this, going to start typing things and then hopefully I'll reach a conclusion by the end.

This definitely needs to be outside of the core solr repo so that it can be versioned and released independently. And I disagree with Ishan about the consequence of abandoning the repository - if we realize that it's a bad direction then we can pivot, but we shouldn't let a fear of the unknown stop us from doing it in the first place.

However, if all we need right now is a place to commit code that is WIP, then what we really want is a sandbox to play with, and not necessarily a strongly directed repo. Lucene has a sandbox in the main code. We could similarly start this under Solr contrib and move it out before an actual release of 9x happens. Or maybe we start with a [lucene-]solr-sandbox repository that we can throw all sorts of stuff into and then when components are mature enough they get to graduate into their own repo?

Mike

On Thu, Jan 7, 2021 at 2:32 PM Anshum Gupta <[hidden email]> wrote:
I understand your concern, but this is the placeholder for where the code would be, not what the code would look like. 

Considering we agreed to do this in a repository outside of the core, I believe this is a good place to start. The idea that the release cadence for the cross-dc effort should be different from that of core is an argument in favor of this approach, but I'm happy to talk more about it. 
I just thought that based on the original email, folks were on-board with the idea of this being outside of core Solr artifact/release.

On Thu, Jan 7, 2021 at 11:06 AM Ishan Chattopadhyaya <[hidden email]> wrote:
-1 on this. Without finalizing on the shape of how the solution will look like, I don't think we should start a repository: it would be bad if we have to abandon the repository of our approach changes (say we want to keep it tightly integrated inside Solr).

On Thu, 7 Jan, 2021, 11:45 pm Anshum Gupta, <[hidden email]> wrote:
Hi everyone,

Inline with my earlier email, I'll be requesting a new repository to host the cross-dc work. Please let me know if you have any questions or concerns.

Repository name: solr-crossdc
Generated name: lucene-solr-crossdc.git (that's auto-generated, so can't remove the TLP prefix)
Commit notification list: [hidden email] (I think it makes sense for these commit notifications to go to a new list, but I'm open to reusing the old one)
GitHub notification list: [hidden email]

I'll be submitting a request for the same later in the day today if there are no concerns.

--
Anshum Gupta


--
Anshum Gupta


--
Anshum Gupta
Reply | Threaded
Open this post in threaded view
|

Re: Requesting a new GH repository for CrossDC modules

Ishan Chattopadhyaya
Not necessarily. Most people contribute to Apache Lucene/Solr using external repositories (forks) and raise pull requests against Apache owned repositories. There's no SGA needed on such occasions.

I see two paths forward from here.

a) Lets setup a single repository for all packages/plugins, say lucene-solr-extras or lucene-solr-contribs or lucene-solr-sandbox etc., and develop it there.
b) All development for this effort happens in an external repository (https://github.com/apple/solr-dc or https://github.com/anshumg/solr-dc) and we raise a PR against Apache owned repository (which can be created if needed once we are all onboard).

What does everyone else think?

On Fri, Jan 8, 2021 at 10:23 AM Mike Drob <[hidden email]> wrote:
An external repository probably ends up requiring a software grant? I know there is a material difference between code originating externally and code originating within the umbrella of the ASF in terms of IP, copyright, or other legal status. 


On Thu, Jan 7, 2021 at 8:11 PM Ishan Chattopadhyaya <[hidden email]> wrote:
If all we need now is a place to commit a PoC for now (and something like sandbox repo or contribs won't suffice), why can't we have a separate repository in GitHub outside Apache and merge into an Apache repository only once the code takes reasonable shape?

On Fri, 8 Jan, 2021, 2:31 am Anshum Gupta, <[hidden email]> wrote:
Thanks for the feedback, Mike.

I like the idea of the sandbox, but that might be restricting when we want to work on more than one repos.

I'm not sure if that would happen in the near future, but as we can always discard the repo and it doesn't really come at a cost, I don't see a problem with having a repo created for this specific reason.

On Thu, Jan 7, 2021 at 12:45 PM Mike Drob <[hidden email]> wrote:
I'm not sure where I sit on this, going to start typing things and then hopefully I'll reach a conclusion by the end.

This definitely needs to be outside of the core solr repo so that it can be versioned and released independently. And I disagree with Ishan about the consequence of abandoning the repository - if we realize that it's a bad direction then we can pivot, but we shouldn't let a fear of the unknown stop us from doing it in the first place.

However, if all we need right now is a place to commit code that is WIP, then what we really want is a sandbox to play with, and not necessarily a strongly directed repo. Lucene has a sandbox in the main code. We could similarly start this under Solr contrib and move it out before an actual release of 9x happens. Or maybe we start with a [lucene-]solr-sandbox repository that we can throw all sorts of stuff into and then when components are mature enough they get to graduate into their own repo?

Mike

On Thu, Jan 7, 2021 at 2:32 PM Anshum Gupta <[hidden email]> wrote:
I understand your concern, but this is the placeholder for where the code would be, not what the code would look like. 

Considering we agreed to do this in a repository outside of the core, I believe this is a good place to start. The idea that the release cadence for the cross-dc effort should be different from that of core is an argument in favor of this approach, but I'm happy to talk more about it. 
I just thought that based on the original email, folks were on-board with the idea of this being outside of core Solr artifact/release.

On Thu, Jan 7, 2021 at 11:06 AM Ishan Chattopadhyaya <[hidden email]> wrote:
-1 on this. Without finalizing on the shape of how the solution will look like, I don't think we should start a repository: it would be bad if we have to abandon the repository of our approach changes (say we want to keep it tightly integrated inside Solr).

On Thu, 7 Jan, 2021, 11:45 pm Anshum Gupta, <[hidden email]> wrote:
Hi everyone,

Inline with my earlier email, I'll be requesting a new repository to host the cross-dc work. Please let me know if you have any questions or concerns.

Repository name: solr-crossdc
Generated name: lucene-solr-crossdc.git (that's auto-generated, so can't remove the TLP prefix)
Commit notification list: [hidden email] (I think it makes sense for these commit notifications to go to a new list, but I'm open to reusing the old one)
GitHub notification list: [hidden email]

I'll be submitting a request for the same later in the day today if there are no concerns.

--
Anshum Gupta


--
Anshum Gupta


--
Anshum Gupta
Reply | Threaded
Open this post in threaded view
|

Re: Requesting a new GH repository for CrossDC modules

Anshum Gupta
The problem with a single repository is that it will/may conflict at times. Also, I still don't see the problem with having the extra repo as long as we aren't releasing anything.

The problem with (b) is that you can't create a PR from a random repository to a repo it isn't a fork of. I also don't think people should own code and build outside of the ASF umbrella until things are ready to be released, it's completely against the Apache Way. Having the code in the ASF umbrella comes at no cost to the project. If at any point it needs to be dropped, it's easier and cleaner as it wouldn't touch anything else.

Does this make sense?


On Fri, Jan 8, 2021 at 1:46 AM Ishan Chattopadhyaya <[hidden email]> wrote:
Not necessarily. Most people contribute to Apache Lucene/Solr using external repositories (forks) and raise pull requests against Apache owned repositories. There's no SGA needed on such occasions.

I see two paths forward from here.

a) Lets setup a single repository for all packages/plugins, say lucene-solr-extras or lucene-solr-contribs or lucene-solr-sandbox etc., and develop it there.
b) All development for this effort happens in an external repository (https://github.com/apple/solr-dc or https://github.com/anshumg/solr-dc) and we raise a PR against Apache owned repository (which can be created if needed once we are all onboard).

What does everyone else think?

On Fri, Jan 8, 2021 at 10:23 AM Mike Drob <[hidden email]> wrote:
An external repository probably ends up requiring a software grant? I know there is a material difference between code originating externally and code originating within the umbrella of the ASF in terms of IP, copyright, or other legal status. 


On Thu, Jan 7, 2021 at 8:11 PM Ishan Chattopadhyaya <[hidden email]> wrote:
If all we need now is a place to commit a PoC for now (and something like sandbox repo or contribs won't suffice), why can't we have a separate repository in GitHub outside Apache and merge into an Apache repository only once the code takes reasonable shape?

On Fri, 8 Jan, 2021, 2:31 am Anshum Gupta, <[hidden email]> wrote:
Thanks for the feedback, Mike.

I like the idea of the sandbox, but that might be restricting when we want to work on more than one repos.

I'm not sure if that would happen in the near future, but as we can always discard the repo and it doesn't really come at a cost, I don't see a problem with having a repo created for this specific reason.

On Thu, Jan 7, 2021 at 12:45 PM Mike Drob <[hidden email]> wrote:
I'm not sure where I sit on this, going to start typing things and then hopefully I'll reach a conclusion by the end.

This definitely needs to be outside of the core solr repo so that it can be versioned and released independently. And I disagree with Ishan about the consequence of abandoning the repository - if we realize that it's a bad direction then we can pivot, but we shouldn't let a fear of the unknown stop us from doing it in the first place.

However, if all we need right now is a place to commit code that is WIP, then what we really want is a sandbox to play with, and not necessarily a strongly directed repo. Lucene has a sandbox in the main code. We could similarly start this under Solr contrib and move it out before an actual release of 9x happens. Or maybe we start with a [lucene-]solr-sandbox repository that we can throw all sorts of stuff into and then when components are mature enough they get to graduate into their own repo?

Mike

On Thu, Jan 7, 2021 at 2:32 PM Anshum Gupta <[hidden email]> wrote:
I understand your concern, but this is the placeholder for where the code would be, not what the code would look like. 

Considering we agreed to do this in a repository outside of the core, I believe this is a good place to start. The idea that the release cadence for the cross-dc effort should be different from that of core is an argument in favor of this approach, but I'm happy to talk more about it. 
I just thought that based on the original email, folks were on-board with the idea of this being outside of core Solr artifact/release.

On Thu, Jan 7, 2021 at 11:06 AM Ishan Chattopadhyaya <[hidden email]> wrote:
-1 on this. Without finalizing on the shape of how the solution will look like, I don't think we should start a repository: it would be bad if we have to abandon the repository of our approach changes (say we want to keep it tightly integrated inside Solr).

On Thu, 7 Jan, 2021, 11:45 pm Anshum Gupta, <[hidden email]> wrote:
Hi everyone,

Inline with my earlier email, I'll be requesting a new repository to host the cross-dc work. Please let me know if you have any questions or concerns.

Repository name: solr-crossdc
Generated name: lucene-solr-crossdc.git (that's auto-generated, so can't remove the TLP prefix)
Commit notification list: [hidden email] (I think it makes sense for these commit notifications to go to a new list, but I'm open to reusing the old one)
GitHub notification list: [hidden email]

I'll be submitting a request for the same later in the day today if there are no concerns.

--
Anshum Gupta


--
Anshum Gupta


--
Anshum Gupta


--
Anshum Gupta
Reply | Threaded
Open this post in threaded view
|

Re: Requesting a new GH repository for CrossDC modules

David Smiley
In reply to this post by Ishan Chattopadhyaya
While I like the idea of a single (Apache!) repo for multiple packages/plugins, that does not apply to the Solr Operator, which isn't even in Java.  It's too unique.  So I agree with Anshum & others about creating an Apache repo for the Solr Operator.

I think the ship has sailed on the Solr Operator being an Apache project instead of some committer's pet project.

~ David Smiley
Apache Lucene/Solr Search Developer


On Fri, Jan 8, 2021 at 4:47 AM Ishan Chattopadhyaya <[hidden email]> wrote:
Not necessarily. Most people contribute to Apache Lucene/Solr using external repositories (forks) and raise pull requests against Apache owned repositories. There's no SGA needed on such occasions.

I see two paths forward from here.

a) Lets setup a single repository for all packages/plugins, say lucene-solr-extras or lucene-solr-contribs or lucene-solr-sandbox etc., and develop it there.
b) All development for this effort happens in an external repository (https://github.com/apple/solr-dc or https://github.com/anshumg/solr-dc) and we raise a PR against Apache owned repository (which can be created if needed once we are all onboard).

What does everyone else think?

On Fri, Jan 8, 2021 at 10:23 AM Mike Drob <[hidden email]> wrote:
An external repository probably ends up requiring a software grant? I know there is a material difference between code originating externally and code originating within the umbrella of the ASF in terms of IP, copyright, or other legal status. 


On Thu, Jan 7, 2021 at 8:11 PM Ishan Chattopadhyaya <[hidden email]> wrote:
If all we need now is a place to commit a PoC for now (and something like sandbox repo or contribs won't suffice), why can't we have a separate repository in GitHub outside Apache and merge into an Apache repository only once the code takes reasonable shape?

On Fri, 8 Jan, 2021, 2:31 am Anshum Gupta, <[hidden email]> wrote:
Thanks for the feedback, Mike.

I like the idea of the sandbox, but that might be restricting when we want to work on more than one repos.

I'm not sure if that would happen in the near future, but as we can always discard the repo and it doesn't really come at a cost, I don't see a problem with having a repo created for this specific reason.

On Thu, Jan 7, 2021 at 12:45 PM Mike Drob <[hidden email]> wrote:
I'm not sure where I sit on this, going to start typing things and then hopefully I'll reach a conclusion by the end.

This definitely needs to be outside of the core solr repo so that it can be versioned and released independently. And I disagree with Ishan about the consequence of abandoning the repository - if we realize that it's a bad direction then we can pivot, but we shouldn't let a fear of the unknown stop us from doing it in the first place.

However, if all we need right now is a place to commit code that is WIP, then what we really want is a sandbox to play with, and not necessarily a strongly directed repo. Lucene has a sandbox in the main code. We could similarly start this under Solr contrib and move it out before an actual release of 9x happens. Or maybe we start with a [lucene-]solr-sandbox repository that we can throw all sorts of stuff into and then when components are mature enough they get to graduate into their own repo?

Mike

On Thu, Jan 7, 2021 at 2:32 PM Anshum Gupta <[hidden email]> wrote:
I understand your concern, but this is the placeholder for where the code would be, not what the code would look like. 

Considering we agreed to do this in a repository outside of the core, I believe this is a good place to start. The idea that the release cadence for the cross-dc effort should be different from that of core is an argument in favor of this approach, but I'm happy to talk more about it. 
I just thought that based on the original email, folks were on-board with the idea of this being outside of core Solr artifact/release.

On Thu, Jan 7, 2021 at 11:06 AM Ishan Chattopadhyaya <[hidden email]> wrote:
-1 on this. Without finalizing on the shape of how the solution will look like, I don't think we should start a repository: it would be bad if we have to abandon the repository of our approach changes (say we want to keep it tightly integrated inside Solr).

On Thu, 7 Jan, 2021, 11:45 pm Anshum Gupta, <[hidden email]> wrote:
Hi everyone,

Inline with my earlier email, I'll be requesting a new repository to host the cross-dc work. Please let me know if you have any questions or concerns.

Repository name: solr-crossdc
Generated name: lucene-solr-crossdc.git (that's auto-generated, so can't remove the TLP prefix)
Commit notification list: [hidden email] (I think it makes sense for these commit notifications to go to a new list, but I'm open to reusing the old one)
GitHub notification list: [hidden email]

I'll be submitting a request for the same later in the day today if there are no concerns.

--
Anshum Gupta


--
Anshum Gupta


--
Anshum Gupta
Reply | Threaded
Open this post in threaded view
|

Re: Requesting a new GH repository for CrossDC modules

Anshum Gupta
David, this is about the Cross DC work that was supposed to be done :-)

The independent release cadence is primarily the reason why a new repo makes sense to me in this case. 

On Sat, Jan 9, 2021 at 1:24 PM David Smiley <[hidden email]> wrote:
While I like the idea of a single (Apache!) repo for multiple packages/plugins, that does not apply to the Solr Operator, which isn't even in Java.  It's too unique.  So I agree with Anshum & others about creating an Apache repo for the Solr Operator.

I think the ship has sailed on the Solr Operator being an Apache project instead of some committer's pet project.

~ David Smiley
Apache Lucene/Solr Search Developer


On Fri, Jan 8, 2021 at 4:47 AM Ishan Chattopadhyaya <[hidden email]> wrote:
Not necessarily. Most people contribute to Apache Lucene/Solr using external repositories (forks) and raise pull requests against Apache owned repositories. There's no SGA needed on such occasions.

I see two paths forward from here.

a) Lets setup a single repository for all packages/plugins, say lucene-solr-extras or lucene-solr-contribs or lucene-solr-sandbox etc., and develop it there.
b) All development for this effort happens in an external repository (https://github.com/apple/solr-dc or https://github.com/anshumg/solr-dc) and we raise a PR against Apache owned repository (which can be created if needed once we are all onboard).

What does everyone else think?

On Fri, Jan 8, 2021 at 10:23 AM Mike Drob <[hidden email]> wrote:
An external repository probably ends up requiring a software grant? I know there is a material difference between code originating externally and code originating within the umbrella of the ASF in terms of IP, copyright, or other legal status. 


On Thu, Jan 7, 2021 at 8:11 PM Ishan Chattopadhyaya <[hidden email]> wrote:
If all we need now is a place to commit a PoC for now (and something like sandbox repo or contribs won't suffice), why can't we have a separate repository in GitHub outside Apache and merge into an Apache repository only once the code takes reasonable shape?

On Fri, 8 Jan, 2021, 2:31 am Anshum Gupta, <[hidden email]> wrote:
Thanks for the feedback, Mike.

I like the idea of the sandbox, but that might be restricting when we want to work on more than one repos.

I'm not sure if that would happen in the near future, but as we can always discard the repo and it doesn't really come at a cost, I don't see a problem with having a repo created for this specific reason.

On Thu, Jan 7, 2021 at 12:45 PM Mike Drob <[hidden email]> wrote:
I'm not sure where I sit on this, going to start typing things and then hopefully I'll reach a conclusion by the end.

This definitely needs to be outside of the core solr repo so that it can be versioned and released independently. And I disagree with Ishan about the consequence of abandoning the repository - if we realize that it's a bad direction then we can pivot, but we shouldn't let a fear of the unknown stop us from doing it in the first place.

However, if all we need right now is a place to commit code that is WIP, then what we really want is a sandbox to play with, and not necessarily a strongly directed repo. Lucene has a sandbox in the main code. We could similarly start this under Solr contrib and move it out before an actual release of 9x happens. Or maybe we start with a [lucene-]solr-sandbox repository that we can throw all sorts of stuff into and then when components are mature enough they get to graduate into their own repo?

Mike

On Thu, Jan 7, 2021 at 2:32 PM Anshum Gupta <[hidden email]> wrote:
I understand your concern, but this is the placeholder for where the code would be, not what the code would look like. 

Considering we agreed to do this in a repository outside of the core, I believe this is a good place to start. The idea that the release cadence for the cross-dc effort should be different from that of core is an argument in favor of this approach, but I'm happy to talk more about it. 
I just thought that based on the original email, folks were on-board with the idea of this being outside of core Solr artifact/release.

On Thu, Jan 7, 2021 at 11:06 AM Ishan Chattopadhyaya <[hidden email]> wrote:
-1 on this. Without finalizing on the shape of how the solution will look like, I don't think we should start a repository: it would be bad if we have to abandon the repository of our approach changes (say we want to keep it tightly integrated inside Solr).

On Thu, 7 Jan, 2021, 11:45 pm Anshum Gupta, <[hidden email]> wrote:
Hi everyone,

Inline with my earlier email, I'll be requesting a new repository to host the cross-dc work. Please let me know if you have any questions or concerns.

Repository name: solr-crossdc
Generated name: lucene-solr-crossdc.git (that's auto-generated, so can't remove the TLP prefix)
Commit notification list: [hidden email] (I think it makes sense for these commit notifications to go to a new list, but I'm open to reusing the old one)
GitHub notification list: [hidden email]

I'll be submitting a request for the same later in the day today if there are no concerns.

--
Anshum Gupta


--
Anshum Gupta


--
Anshum Gupta


--
Anshum Gupta
Reply | Threaded
Open this post in threaded view
|

Re: Requesting a new GH repository for CrossDC modules

David Smiley
(palm-to-face) -- LOL okay sorry.  I'm getting my threads crossed.

A repo which holds multiple independent modules that can work with Solr need not release them all at once.

~ David Smiley
Apache Lucene/Solr Search Developer


On Sat, Jan 9, 2021 at 4:48 PM Anshum Gupta <[hidden email]> wrote:
David, this is about the Cross DC work that was supposed to be done :-)

The independent release cadence is primarily the reason why a new repo makes sense to me in this case. 

On Sat, Jan 9, 2021 at 1:24 PM David Smiley <[hidden email]> wrote:
While I like the idea of a single (Apache!) repo for multiple packages/plugins, that does not apply to the Solr Operator, which isn't even in Java.  It's too unique.  So I agree with Anshum & others about creating an Apache repo for the Solr Operator.

I think the ship has sailed on the Solr Operator being an Apache project instead of some committer's pet project.

~ David Smiley
Apache Lucene/Solr Search Developer


On Fri, Jan 8, 2021 at 4:47 AM Ishan Chattopadhyaya <[hidden email]> wrote:
Not necessarily. Most people contribute to Apache Lucene/Solr using external repositories (forks) and raise pull requests against Apache owned repositories. There's no SGA needed on such occasions.

I see two paths forward from here.

a) Lets setup a single repository for all packages/plugins, say lucene-solr-extras or lucene-solr-contribs or lucene-solr-sandbox etc., and develop it there.
b) All development for this effort happens in an external repository (https://github.com/apple/solr-dc or https://github.com/anshumg/solr-dc) and we raise a PR against Apache owned repository (which can be created if needed once we are all onboard).

What does everyone else think?

On Fri, Jan 8, 2021 at 10:23 AM Mike Drob <[hidden email]> wrote:
An external repository probably ends up requiring a software grant? I know there is a material difference between code originating externally and code originating within the umbrella of the ASF in terms of IP, copyright, or other legal status. 


On Thu, Jan 7, 2021 at 8:11 PM Ishan Chattopadhyaya <[hidden email]> wrote:
If all we need now is a place to commit a PoC for now (and something like sandbox repo or contribs won't suffice), why can't we have a separate repository in GitHub outside Apache and merge into an Apache repository only once the code takes reasonable shape?

On Fri, 8 Jan, 2021, 2:31 am Anshum Gupta, <[hidden email]> wrote:
Thanks for the feedback, Mike.

I like the idea of the sandbox, but that might be restricting when we want to work on more than one repos.

I'm not sure if that would happen in the near future, but as we can always discard the repo and it doesn't really come at a cost, I don't see a problem with having a repo created for this specific reason.

On Thu, Jan 7, 2021 at 12:45 PM Mike Drob <[hidden email]> wrote:
I'm not sure where I sit on this, going to start typing things and then hopefully I'll reach a conclusion by the end.

This definitely needs to be outside of the core solr repo so that it can be versioned and released independently. And I disagree with Ishan about the consequence of abandoning the repository - if we realize that it's a bad direction then we can pivot, but we shouldn't let a fear of the unknown stop us from doing it in the first place.

However, if all we need right now is a place to commit code that is WIP, then what we really want is a sandbox to play with, and not necessarily a strongly directed repo. Lucene has a sandbox in the main code. We could similarly start this under Solr contrib and move it out before an actual release of 9x happens. Or maybe we start with a [lucene-]solr-sandbox repository that we can throw all sorts of stuff into and then when components are mature enough they get to graduate into their own repo?

Mike

On Thu, Jan 7, 2021 at 2:32 PM Anshum Gupta <[hidden email]> wrote:
I understand your concern, but this is the placeholder for where the code would be, not what the code would look like. 

Considering we agreed to do this in a repository outside of the core, I believe this is a good place to start. The idea that the release cadence for the cross-dc effort should be different from that of core is an argument in favor of this approach, but I'm happy to talk more about it. 
I just thought that based on the original email, folks were on-board with the idea of this being outside of core Solr artifact/release.

On Thu, Jan 7, 2021 at 11:06 AM Ishan Chattopadhyaya <[hidden email]> wrote:
-1 on this. Without finalizing on the shape of how the solution will look like, I don't think we should start a repository: it would be bad if we have to abandon the repository of our approach changes (say we want to keep it tightly integrated inside Solr).

On Thu, 7 Jan, 2021, 11:45 pm Anshum Gupta, <[hidden email]> wrote:
Hi everyone,

Inline with my earlier email, I'll be requesting a new repository to host the cross-dc work. Please let me know if you have any questions or concerns.

Repository name: solr-crossdc
Generated name: lucene-solr-crossdc.git (that's auto-generated, so can't remove the TLP prefix)
Commit notification list: [hidden email] (I think it makes sense for these commit notifications to go to a new list, but I'm open to reusing the old one)
GitHub notification list: [hidden email]

I'll be submitting a request for the same later in the day today if there are no concerns.

--
Anshum Gupta


--
Anshum Gupta


--
Anshum Gupta


--
Anshum Gupta
Reply | Threaded
Open this post in threaded view
|

Re: Requesting a new GH repository for CrossDC modules

Mike Drob-3
I'm seeing valid reasons to prefer one solr sandbox repo, or prefer multiple many repos for future plugins or integrations. In this specific case, I think the relevant deciding points are 1) we don't have multiple things yet, so deciding between a "mono-repo" and a "multi-repo" is not very consequential 2) we can always rename things later 3) in the absence of a strong reason otherwise i'll defer to the people doing the work (in this case, Anshum). We considered sandbox and can always create one in the future. If Anshum feels that solr-cross-dc is better for now than I'm fine with that too.

On Sun, Jan 10, 2021 at 5:07 PM David Smiley <[hidden email]> wrote:
(palm-to-face) -- LOL okay sorry.  I'm getting my threads crossed.

A repo which holds multiple independent modules that can work with Solr need not release them all at once.

~ David Smiley
Apache Lucene/Solr Search Developer


On Sat, Jan 9, 2021 at 4:48 PM Anshum Gupta <[hidden email]> wrote:
David, this is about the Cross DC work that was supposed to be done :-)

The independent release cadence is primarily the reason why a new repo makes sense to me in this case. 

On Sat, Jan 9, 2021 at 1:24 PM David Smiley <[hidden email]> wrote:
While I like the idea of a single (Apache!) repo for multiple packages/plugins, that does not apply to the Solr Operator, which isn't even in Java.  It's too unique.  So I agree with Anshum & others about creating an Apache repo for the Solr Operator.

I think the ship has sailed on the Solr Operator being an Apache project instead of some committer's pet project.

~ David Smiley
Apache Lucene/Solr Search Developer


On Fri, Jan 8, 2021 at 4:47 AM Ishan Chattopadhyaya <[hidden email]> wrote:
Not necessarily. Most people contribute to Apache Lucene/Solr using external repositories (forks) and raise pull requests against Apache owned repositories. There's no SGA needed on such occasions.

I see two paths forward from here.

a) Lets setup a single repository for all packages/plugins, say lucene-solr-extras or lucene-solr-contribs or lucene-solr-sandbox etc., and develop it there.
b) All development for this effort happens in an external repository (https://github.com/apple/solr-dc or https://github.com/anshumg/solr-dc) and we raise a PR against Apache owned repository (which can be created if needed once we are all onboard).

What does everyone else think?

On Fri, Jan 8, 2021 at 10:23 AM Mike Drob <[hidden email]> wrote:
An external repository probably ends up requiring a software grant? I know there is a material difference between code originating externally and code originating within the umbrella of the ASF in terms of IP, copyright, or other legal status. 


On Thu, Jan 7, 2021 at 8:11 PM Ishan Chattopadhyaya <[hidden email]> wrote:
If all we need now is a place to commit a PoC for now (and something like sandbox repo or contribs won't suffice), why can't we have a separate repository in GitHub outside Apache and merge into an Apache repository only once the code takes reasonable shape?

On Fri, 8 Jan, 2021, 2:31 am Anshum Gupta, <[hidden email]> wrote:
Thanks for the feedback, Mike.

I like the idea of the sandbox, but that might be restricting when we want to work on more than one repos.

I'm not sure if that would happen in the near future, but as we can always discard the repo and it doesn't really come at a cost, I don't see a problem with having a repo created for this specific reason.

On Thu, Jan 7, 2021 at 12:45 PM Mike Drob <[hidden email]> wrote:
I'm not sure where I sit on this, going to start typing things and then hopefully I'll reach a conclusion by the end.

This definitely needs to be outside of the core solr repo so that it can be versioned and released independently. And I disagree with Ishan about the consequence of abandoning the repository - if we realize that it's a bad direction then we can pivot, but we shouldn't let a fear of the unknown stop us from doing it in the first place.

However, if all we need right now is a place to commit code that is WIP, then what we really want is a sandbox to play with, and not necessarily a strongly directed repo. Lucene has a sandbox in the main code. We could similarly start this under Solr contrib and move it out before an actual release of 9x happens. Or maybe we start with a [lucene-]solr-sandbox repository that we can throw all sorts of stuff into and then when components are mature enough they get to graduate into their own repo?

Mike

On Thu, Jan 7, 2021 at 2:32 PM Anshum Gupta <[hidden email]> wrote:
I understand your concern, but this is the placeholder for where the code would be, not what the code would look like. 

Considering we agreed to do this in a repository outside of the core, I believe this is a good place to start. The idea that the release cadence for the cross-dc effort should be different from that of core is an argument in favor of this approach, but I'm happy to talk more about it. 
I just thought that based on the original email, folks were on-board with the idea of this being outside of core Solr artifact/release.

On Thu, Jan 7, 2021 at 11:06 AM Ishan Chattopadhyaya <[hidden email]> wrote:
-1 on this. Without finalizing on the shape of how the solution will look like, I don't think we should start a repository: it would be bad if we have to abandon the repository of our approach changes (say we want to keep it tightly integrated inside Solr).

On Thu, 7 Jan, 2021, 11:45 pm Anshum Gupta, <[hidden email]> wrote:
Hi everyone,

Inline with my earlier email, I'll be requesting a new repository to host the cross-dc work. Please let me know if you have any questions or concerns.

Repository name: solr-crossdc
Generated name: lucene-solr-crossdc.git (that's auto-generated, so can't remove the TLP prefix)
Commit notification list: [hidden email] (I think it makes sense for these commit notifications to go to a new list, but I'm open to reusing the old one)
GitHub notification list: [hidden email]

I'll be submitting a request for the same later in the day today if there are no concerns.

--
Anshum Gupta


--
Anshum Gupta


--
Anshum Gupta


--
Anshum Gupta
Reply | Threaded
Open this post in threaded view
|

Re: Requesting a new GH repository for CrossDC modules

Anshum Gupta
Thank you everyone! 

I'll move forward with the cross-dc repo creation then as mentioned in the original email :)

If we want to change the approach on the repo, we can always change that before we release anything in the future.

On Mon, Jan 11, 2021 at 10:32 AM Mike Drob <[hidden email]> wrote:
I'm seeing valid reasons to prefer one solr sandbox repo, or prefer multiple many repos for future plugins or integrations. In this specific case, I think the relevant deciding points are 1) we don't have multiple things yet, so deciding between a "mono-repo" and a "multi-repo" is not very consequential 2) we can always rename things later 3) in the absence of a strong reason otherwise i'll defer to the people doing the work (in this case, Anshum). We considered sandbox and can always create one in the future. If Anshum feels that solr-cross-dc is better for now than I'm fine with that too.

On Sun, Jan 10, 2021 at 5:07 PM David Smiley <[hidden email]> wrote:
(palm-to-face) -- LOL okay sorry.  I'm getting my threads crossed.

A repo which holds multiple independent modules that can work with Solr need not release them all at once.

~ David Smiley
Apache Lucene/Solr Search Developer


On Sat, Jan 9, 2021 at 4:48 PM Anshum Gupta <[hidden email]> wrote:
David, this is about the Cross DC work that was supposed to be done :-)

The independent release cadence is primarily the reason why a new repo makes sense to me in this case. 

On Sat, Jan 9, 2021 at 1:24 PM David Smiley <[hidden email]> wrote:
While I like the idea of a single (Apache!) repo for multiple packages/plugins, that does not apply to the Solr Operator, which isn't even in Java.  It's too unique.  So I agree with Anshum & others about creating an Apache repo for the Solr Operator.

I think the ship has sailed on the Solr Operator being an Apache project instead of some committer's pet project.

~ David Smiley
Apache Lucene/Solr Search Developer


On Fri, Jan 8, 2021 at 4:47 AM Ishan Chattopadhyaya <[hidden email]> wrote:
Not necessarily. Most people contribute to Apache Lucene/Solr using external repositories (forks) and raise pull requests against Apache owned repositories. There's no SGA needed on such occasions.

I see two paths forward from here.

a) Lets setup a single repository for all packages/plugins, say lucene-solr-extras or lucene-solr-contribs or lucene-solr-sandbox etc., and develop it there.
b) All development for this effort happens in an external repository (https://github.com/apple/solr-dc or https://github.com/anshumg/solr-dc) and we raise a PR against Apache owned repository (which can be created if needed once we are all onboard).

What does everyone else think?

On Fri, Jan 8, 2021 at 10:23 AM Mike Drob <[hidden email]> wrote:
An external repository probably ends up requiring a software grant? I know there is a material difference between code originating externally and code originating within the umbrella of the ASF in terms of IP, copyright, or other legal status. 


On Thu, Jan 7, 2021 at 8:11 PM Ishan Chattopadhyaya <[hidden email]> wrote:
If all we need now is a place to commit a PoC for now (and something like sandbox repo or contribs won't suffice), why can't we have a separate repository in GitHub outside Apache and merge into an Apache repository only once the code takes reasonable shape?

On Fri, 8 Jan, 2021, 2:31 am Anshum Gupta, <[hidden email]> wrote:
Thanks for the feedback, Mike.

I like the idea of the sandbox, but that might be restricting when we want to work on more than one repos.

I'm not sure if that would happen in the near future, but as we can always discard the repo and it doesn't really come at a cost, I don't see a problem with having a repo created for this specific reason.

On Thu, Jan 7, 2021 at 12:45 PM Mike Drob <[hidden email]> wrote:
I'm not sure where I sit on this, going to start typing things and then hopefully I'll reach a conclusion by the end.

This definitely needs to be outside of the core solr repo so that it can be versioned and released independently. And I disagree with Ishan about the consequence of abandoning the repository - if we realize that it's a bad direction then we can pivot, but we shouldn't let a fear of the unknown stop us from doing it in the first place.

However, if all we need right now is a place to commit code that is WIP, then what we really want is a sandbox to play with, and not necessarily a strongly directed repo. Lucene has a sandbox in the main code. We could similarly start this under Solr contrib and move it out before an actual release of 9x happens. Or maybe we start with a [lucene-]solr-sandbox repository that we can throw all sorts of stuff into and then when components are mature enough they get to graduate into their own repo?

Mike

On Thu, Jan 7, 2021 at 2:32 PM Anshum Gupta <[hidden email]> wrote:
I understand your concern, but this is the placeholder for where the code would be, not what the code would look like. 

Considering we agreed to do this in a repository outside of the core, I believe this is a good place to start. The idea that the release cadence for the cross-dc effort should be different from that of core is an argument in favor of this approach, but I'm happy to talk more about it. 
I just thought that based on the original email, folks were on-board with the idea of this being outside of core Solr artifact/release.

On Thu, Jan 7, 2021 at 11:06 AM Ishan Chattopadhyaya <[hidden email]> wrote:
-1 on this. Without finalizing on the shape of how the solution will look like, I don't think we should start a repository: it would be bad if we have to abandon the repository of our approach changes (say we want to keep it tightly integrated inside Solr).

On Thu, 7 Jan, 2021, 11:45 pm Anshum Gupta, <[hidden email]> wrote:
Hi everyone,

Inline with my earlier email, I'll be requesting a new repository to host the cross-dc work. Please let me know if you have any questions or concerns.

Repository name: solr-crossdc
Generated name: lucene-solr-crossdc.git (that's auto-generated, so can't remove the TLP prefix)
Commit notification list: [hidden email] (I think it makes sense for these commit notifications to go to a new list, but I'm open to reusing the old one)
GitHub notification list: [hidden email]

I'll be submitting a request for the same later in the day today if there are no concerns.

--
Anshum Gupta


--
Anshum Gupta


--
Anshum Gupta


--
Anshum Gupta


--
Anshum Gupta
Reply | Threaded
Open this post in threaded view
|

Re: Requesting a new GH repository for CrossDC modules

Ishan Chattopadhyaya
Look at the branches that are cluttering up our main repository, many symbolic of unfinished work. If we start one repo each for everything we hope to finish, we'll make Solr annoying in a new way. 

There is no reason multiple artifacts can't be released independently from the same repo. Why are you opposed to that idea, Anshum?

On Tue, 12 Jan, 2021, 11:53 pm Anshum Gupta, <[hidden email]> wrote:
Thank you everyone! 

I'll move forward with the cross-dc repo creation then as mentioned in the original email :)

If we want to change the approach on the repo, we can always change that before we release anything in the future.

On Mon, Jan 11, 2021 at 10:32 AM Mike Drob <[hidden email]> wrote:
I'm seeing valid reasons to prefer one solr sandbox repo, or prefer multiple many repos for future plugins or integrations. In this specific case, I think the relevant deciding points are 1) we don't have multiple things yet, so deciding between a "mono-repo" and a "multi-repo" is not very consequential 2) we can always rename things later 3) in the absence of a strong reason otherwise i'll defer to the people doing the work (in this case, Anshum). We considered sandbox and can always create one in the future. If Anshum feels that solr-cross-dc is better for now than I'm fine with that too.

On Sun, Jan 10, 2021 at 5:07 PM David Smiley <[hidden email]> wrote:
(palm-to-face) -- LOL okay sorry.  I'm getting my threads crossed.

A repo which holds multiple independent modules that can work with Solr need not release them all at once.

~ David Smiley
Apache Lucene/Solr Search Developer


On Sat, Jan 9, 2021 at 4:48 PM Anshum Gupta <[hidden email]> wrote:
David, this is about the Cross DC work that was supposed to be done :-)

The independent release cadence is primarily the reason why a new repo makes sense to me in this case. 

On Sat, Jan 9, 2021 at 1:24 PM David Smiley <[hidden email]> wrote:
While I like the idea of a single (Apache!) repo for multiple packages/plugins, that does not apply to the Solr Operator, which isn't even in Java.  It's too unique.  So I agree with Anshum & others about creating an Apache repo for the Solr Operator.

I think the ship has sailed on the Solr Operator being an Apache project instead of some committer's pet project.

~ David Smiley
Apache Lucene/Solr Search Developer


On Fri, Jan 8, 2021 at 4:47 AM Ishan Chattopadhyaya <[hidden email]> wrote:
Not necessarily. Most people contribute to Apache Lucene/Solr using external repositories (forks) and raise pull requests against Apache owned repositories. There's no SGA needed on such occasions.

I see two paths forward from here.

a) Lets setup a single repository for all packages/plugins, say lucene-solr-extras or lucene-solr-contribs or lucene-solr-sandbox etc., and develop it there.
b) All development for this effort happens in an external repository (https://github.com/apple/solr-dc or https://github.com/anshumg/solr-dc) and we raise a PR against Apache owned repository (which can be created if needed once we are all onboard).

What does everyone else think?

On Fri, Jan 8, 2021 at 10:23 AM Mike Drob <[hidden email]> wrote:
An external repository probably ends up requiring a software grant? I know there is a material difference between code originating externally and code originating within the umbrella of the ASF in terms of IP, copyright, or other legal status. 


On Thu, Jan 7, 2021 at 8:11 PM Ishan Chattopadhyaya <[hidden email]> wrote:
If all we need now is a place to commit a PoC for now (and something like sandbox repo or contribs won't suffice), why can't we have a separate repository in GitHub outside Apache and merge into an Apache repository only once the code takes reasonable shape?

On Fri, 8 Jan, 2021, 2:31 am Anshum Gupta, <[hidden email]> wrote:
Thanks for the feedback, Mike.

I like the idea of the sandbox, but that might be restricting when we want to work on more than one repos.

I'm not sure if that would happen in the near future, but as we can always discard the repo and it doesn't really come at a cost, I don't see a problem with having a repo created for this specific reason.

On Thu, Jan 7, 2021 at 12:45 PM Mike Drob <[hidden email]> wrote:
I'm not sure where I sit on this, going to start typing things and then hopefully I'll reach a conclusion by the end.

This definitely needs to be outside of the core solr repo so that it can be versioned and released independently. And I disagree with Ishan about the consequence of abandoning the repository - if we realize that it's a bad direction then we can pivot, but we shouldn't let a fear of the unknown stop us from doing it in the first place.

However, if all we need right now is a place to commit code that is WIP, then what we really want is a sandbox to play with, and not necessarily a strongly directed repo. Lucene has a sandbox in the main code. We could similarly start this under Solr contrib and move it out before an actual release of 9x happens. Or maybe we start with a [lucene-]solr-sandbox repository that we can throw all sorts of stuff into and then when components are mature enough they get to graduate into their own repo?

Mike

On Thu, Jan 7, 2021 at 2:32 PM Anshum Gupta <[hidden email]> wrote:
I understand your concern, but this is the placeholder for where the code would be, not what the code would look like. 

Considering we agreed to do this in a repository outside of the core, I believe this is a good place to start. The idea that the release cadence for the cross-dc effort should be different from that of core is an argument in favor of this approach, but I'm happy to talk more about it. 
I just thought that based on the original email, folks were on-board with the idea of this being outside of core Solr artifact/release.

On Thu, Jan 7, 2021 at 11:06 AM Ishan Chattopadhyaya <[hidden email]> wrote:
-1 on this. Without finalizing on the shape of how the solution will look like, I don't think we should start a repository: it would be bad if we have to abandon the repository of our approach changes (say we want to keep it tightly integrated inside Solr).

On Thu, 7 Jan, 2021, 11:45 pm Anshum Gupta, <[hidden email]> wrote:
Hi everyone,

Inline with my earlier email, I'll be requesting a new repository to host the cross-dc work. Please let me know if you have any questions or concerns.

Repository name: solr-crossdc
Generated name: lucene-solr-crossdc.git (that's auto-generated, so can't remove the TLP prefix)
Commit notification list: [hidden email] (I think it makes sense for these commit notifications to go to a new list, but I'm open to reusing the old one)
GitHub notification list: [hidden email]

I'll be submitting a request for the same later in the day today if there are no concerns.

--
Anshum Gupta


--
Anshum Gupta


--
Anshum Gupta


--
Anshum Gupta


--
Anshum Gupta
Reply | Threaded
Open this post in threaded view
|

Re: Requesting a new GH repository for CrossDC modules

Anshum Gupta
I understand what you are saying, which is also my reason to not have a mono-repo. This way it's easier to manage and drop a repository when it's not needed. It doesn't cause clutter and lives in isolation.

I think we are on the same page in terms of the intention.


On Tue, Jan 12, 2021 at 10:51 AM Ishan Chattopadhyaya <[hidden email]> wrote:
Look at the branches that are cluttering up our main repository, many symbolic of unfinished work. If we start one repo each for everything we hope to finish, we'll make Solr annoying in a new way. 

There is no reason multiple artifacts can't be released independently from the same repo. Why are you opposed to that idea, Anshum?

On Tue, 12 Jan, 2021, 11:53 pm Anshum Gupta, <[hidden email]> wrote:
Thank you everyone! 

I'll move forward with the cross-dc repo creation then as mentioned in the original email :)

If we want to change the approach on the repo, we can always change that before we release anything in the future.

On Mon, Jan 11, 2021 at 10:32 AM Mike Drob <[hidden email]> wrote:
I'm seeing valid reasons to prefer one solr sandbox repo, or prefer multiple many repos for future plugins or integrations. In this specific case, I think the relevant deciding points are 1) we don't have multiple things yet, so deciding between a "mono-repo" and a "multi-repo" is not very consequential 2) we can always rename things later 3) in the absence of a strong reason otherwise i'll defer to the people doing the work (in this case, Anshum). We considered sandbox and can always create one in the future. If Anshum feels that solr-cross-dc is better for now than I'm fine with that too.

On Sun, Jan 10, 2021 at 5:07 PM David Smiley <[hidden email]> wrote:
(palm-to-face) -- LOL okay sorry.  I'm getting my threads crossed.

A repo which holds multiple independent modules that can work with Solr need not release them all at once.

~ David Smiley
Apache Lucene/Solr Search Developer


On Sat, Jan 9, 2021 at 4:48 PM Anshum Gupta <[hidden email]> wrote:
David, this is about the Cross DC work that was supposed to be done :-)

The independent release cadence is primarily the reason why a new repo makes sense to me in this case. 

On Sat, Jan 9, 2021 at 1:24 PM David Smiley <[hidden email]> wrote:
While I like the idea of a single (Apache!) repo for multiple packages/plugins, that does not apply to the Solr Operator, which isn't even in Java.  It's too unique.  So I agree with Anshum & others about creating an Apache repo for the Solr Operator.

I think the ship has sailed on the Solr Operator being an Apache project instead of some committer's pet project.

~ David Smiley
Apache Lucene/Solr Search Developer


On Fri, Jan 8, 2021 at 4:47 AM Ishan Chattopadhyaya <[hidden email]> wrote:
Not necessarily. Most people contribute to Apache Lucene/Solr using external repositories (forks) and raise pull requests against Apache owned repositories. There's no SGA needed on such occasions.

I see two paths forward from here.

a) Lets setup a single repository for all packages/plugins, say lucene-solr-extras or lucene-solr-contribs or lucene-solr-sandbox etc., and develop it there.
b) All development for this effort happens in an external repository (https://github.com/apple/solr-dc or https://github.com/anshumg/solr-dc) and we raise a PR against Apache owned repository (which can be created if needed once we are all onboard).

What does everyone else think?

On Fri, Jan 8, 2021 at 10:23 AM Mike Drob <[hidden email]> wrote:
An external repository probably ends up requiring a software grant? I know there is a material difference between code originating externally and code originating within the umbrella of the ASF in terms of IP, copyright, or other legal status. 


On Thu, Jan 7, 2021 at 8:11 PM Ishan Chattopadhyaya <[hidden email]> wrote:
If all we need now is a place to commit a PoC for now (and something like sandbox repo or contribs won't suffice), why can't we have a separate repository in GitHub outside Apache and merge into an Apache repository only once the code takes reasonable shape?

On Fri, 8 Jan, 2021, 2:31 am Anshum Gupta, <[hidden email]> wrote:
Thanks for the feedback, Mike.

I like the idea of the sandbox, but that might be restricting when we want to work on more than one repos.

I'm not sure if that would happen in the near future, but as we can always discard the repo and it doesn't really come at a cost, I don't see a problem with having a repo created for this specific reason.

On Thu, Jan 7, 2021 at 12:45 PM Mike Drob <[hidden email]> wrote:
I'm not sure where I sit on this, going to start typing things and then hopefully I'll reach a conclusion by the end.

This definitely needs to be outside of the core solr repo so that it can be versioned and released independently. And I disagree with Ishan about the consequence of abandoning the repository - if we realize that it's a bad direction then we can pivot, but we shouldn't let a fear of the unknown stop us from doing it in the first place.

However, if all we need right now is a place to commit code that is WIP, then what we really want is a sandbox to play with, and not necessarily a strongly directed repo. Lucene has a sandbox in the main code. We could similarly start this under Solr contrib and move it out before an actual release of 9x happens. Or maybe we start with a [lucene-]solr-sandbox repository that we can throw all sorts of stuff into and then when components are mature enough they get to graduate into their own repo?

Mike

On Thu, Jan 7, 2021 at 2:32 PM Anshum Gupta <[hidden email]> wrote:
I understand your concern, but this is the placeholder for where the code would be, not what the code would look like. 

Considering we agreed to do this in a repository outside of the core, I believe this is a good place to start. The idea that the release cadence for the cross-dc effort should be different from that of core is an argument in favor of this approach, but I'm happy to talk more about it. 
I just thought that based on the original email, folks were on-board with the idea of this being outside of core Solr artifact/release.

On Thu, Jan 7, 2021 at 11:06 AM Ishan Chattopadhyaya <[hidden email]> wrote:
-1 on this. Without finalizing on the shape of how the solution will look like, I don't think we should start a repository: it would be bad if we have to abandon the repository of our approach changes (say we want to keep it tightly integrated inside Solr).

On Thu, 7 Jan, 2021, 11:45 pm Anshum Gupta, <[hidden email]> wrote:
Hi everyone,

Inline with my earlier email, I'll be requesting a new repository to host the cross-dc work. Please let me know if you have any questions or concerns.

Repository name: solr-crossdc
Generated name: lucene-solr-crossdc.git (that's auto-generated, so can't remove the TLP prefix)
Commit notification list: [hidden email] (I think it makes sense for these commit notifications to go to a new list, but I'm open to reusing the old one)
GitHub notification list: [hidden email]

I'll be submitting a request for the same later in the day today if there are no concerns.

--
Anshum Gupta


--
Anshum Gupta


--
Anshum Gupta


--
Anshum Gupta


--
Anshum Gupta


--
Anshum Gupta
Reply | Threaded
Open this post in threaded view
|

Re: Requesting a new GH repository for CrossDC modules

Noble Paul നോബിള്‍  नोब्ळ्
I feel this is placing the cart before the horse.

We can always build this as a branch or a repo under your own account.
Once we reach a point where the project is reasonably mature, you can
create a repo and contribute it upstream.


On Wed, Jan 13, 2021 at 6:27 AM Anshum Gupta <[hidden email]> wrote:

>
> I understand what you are saying, which is also my reason to not have a mono-repo. This way it's easier to manage and drop a repository when it's not needed. It doesn't cause clutter and lives in isolation.
>
> I think we are on the same page in terms of the intention.
>
>
> On Tue, Jan 12, 2021 at 10:51 AM Ishan Chattopadhyaya <[hidden email]> wrote:
>>
>> Look at the branches that are cluttering up our main repository, many symbolic of unfinished work. If we start one repo each for everything we hope to finish, we'll make Solr annoying in a new way.
>>
>> There is no reason multiple artifacts can't be released independently from the same repo. Why are you opposed to that idea, Anshum?
>>
>> On Tue, 12 Jan, 2021, 11:53 pm Anshum Gupta, <[hidden email]> wrote:
>>>
>>> Thank you everyone!
>>>
>>> I'll move forward with the cross-dc repo creation then as mentioned in the original email :)
>>>
>>> If we want to change the approach on the repo, we can always change that before we release anything in the future.
>>>
>>> On Mon, Jan 11, 2021 at 10:32 AM Mike Drob <[hidden email]> wrote:
>>>>
>>>> I'm seeing valid reasons to prefer one solr sandbox repo, or prefer multiple many repos for future plugins or integrations. In this specific case, I think the relevant deciding points are 1) we don't have multiple things yet, so deciding between a "mono-repo" and a "multi-repo" is not very consequential 2) we can always rename things later 3) in the absence of a strong reason otherwise i'll defer to the people doing the work (in this case, Anshum). We considered sandbox and can always create one in the future. If Anshum feels that solr-cross-dc is better for now than I'm fine with that too.
>>>>
>>>> On Sun, Jan 10, 2021 at 5:07 PM David Smiley <[hidden email]> wrote:
>>>>>
>>>>> (palm-to-face) -- LOL okay sorry.  I'm getting my threads crossed.
>>>>>
>>>>> A repo which holds multiple independent modules that can work with Solr need not release them all at once.
>>>>>
>>>>> ~ David Smiley
>>>>> Apache Lucene/Solr Search Developer
>>>>> http://www.linkedin.com/in/davidwsmiley
>>>>>
>>>>>
>>>>> On Sat, Jan 9, 2021 at 4:48 PM Anshum Gupta <[hidden email]> wrote:
>>>>>>
>>>>>> David, this is about the Cross DC work that was supposed to be done :-)
>>>>>>
>>>>>> The independent release cadence is primarily the reason why a new repo makes sense to me in this case.
>>>>>>
>>>>>> On Sat, Jan 9, 2021 at 1:24 PM David Smiley <[hidden email]> wrote:
>>>>>>>
>>>>>>> While I like the idea of a single (Apache!) repo for multiple packages/plugins, that does not apply to the Solr Operator, which isn't even in Java.  It's too unique.  So I agree with Anshum & others about creating an Apache repo for the Solr Operator.
>>>>>>>
>>>>>>> I think the ship has sailed on the Solr Operator being an Apache project instead of some committer's pet project.
>>>>>>>
>>>>>>> ~ David Smiley
>>>>>>> Apache Lucene/Solr Search Developer
>>>>>>> http://www.linkedin.com/in/davidwsmiley
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jan 8, 2021 at 4:47 AM Ishan Chattopadhyaya <[hidden email]> wrote:
>>>>>>>>
>>>>>>>> Not necessarily. Most people contribute to Apache Lucene/Solr using external repositories (forks) and raise pull requests against Apache owned repositories. There's no SGA needed on such occasions.
>>>>>>>>
>>>>>>>> I see two paths forward from here.
>>>>>>>>
>>>>>>>> a) Lets setup a single repository for all packages/plugins, say lucene-solr-extras or lucene-solr-contribs or lucene-solr-sandbox etc., and develop it there.
>>>>>>>> b) All development for this effort happens in an external repository (https://github.com/apple/solr-dc or https://github.com/anshumg/solr-dc) and we raise a PR against Apache owned repository (which can be created if needed once we are all onboard).
>>>>>>>>
>>>>>>>> What does everyone else think?
>>>>>>>>
>>>>>>>> On Fri, Jan 8, 2021 at 10:23 AM Mike Drob <[hidden email]> wrote:
>>>>>>>>>
>>>>>>>>> An external repository probably ends up requiring a software grant? I know there is a material difference between code originating externally and code originating within the umbrella of the ASF in terms of IP, copyright, or other legal status.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Jan 7, 2021 at 8:11 PM Ishan Chattopadhyaya <[hidden email]> wrote:
>>>>>>>>>>
>>>>>>>>>> If all we need now is a place to commit a PoC for now (and something like sandbox repo or contribs won't suffice), why can't we have a separate repository in GitHub outside Apache and merge into an Apache repository only once the code takes reasonable shape?
>>>>>>>>>>
>>>>>>>>>> On Fri, 8 Jan, 2021, 2:31 am Anshum Gupta, <[hidden email]> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Thanks for the feedback, Mike.
>>>>>>>>>>>
>>>>>>>>>>> I like the idea of the sandbox, but that might be restricting when we want to work on more than one repos.
>>>>>>>>>>>
>>>>>>>>>>> I'm not sure if that would happen in the near future, but as we can always discard the repo and it doesn't really come at a cost, I don't see a problem with having a repo created for this specific reason.
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Jan 7, 2021 at 12:45 PM Mike Drob <[hidden email]> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> I'm not sure where I sit on this, going to start typing things and then hopefully I'll reach a conclusion by the end.
>>>>>>>>>>>>
>>>>>>>>>>>> This definitely needs to be outside of the core solr repo so that it can be versioned and released independently. And I disagree with Ishan about the consequence of abandoning the repository - if we realize that it's a bad direction then we can pivot, but we shouldn't let a fear of the unknown stop us from doing it in the first place.
>>>>>>>>>>>>
>>>>>>>>>>>> However, if all we need right now is a place to commit code that is WIP, then what we really want is a sandbox to play with, and not necessarily a strongly directed repo. Lucene has a sandbox in the main code. We could similarly start this under Solr contrib and move it out before an actual release of 9x happens. Or maybe we start with a [lucene-]solr-sandbox repository that we can throw all sorts of stuff into and then when components are mature enough they get to graduate into their own repo?
>>>>>>>>>>>>
>>>>>>>>>>>> Mike
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Jan 7, 2021 at 2:32 PM Anshum Gupta <[hidden email]> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> I understand your concern, but this is the placeholder for where the code would be, not what the code would look like.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Considering we agreed to do this in a repository outside of the core, I believe this is a good place to start. The idea that the release cadence for the cross-dc effort should be different from that of core is an argument in favor of this approach, but I'm happy to talk more about it.
>>>>>>>>>>>>> I just thought that based on the original email, folks were on-board with the idea of this being outside of core Solr artifact/release.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Jan 7, 2021 at 11:06 AM Ishan Chattopadhyaya <[hidden email]> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -1 on this. Without finalizing on the shape of how the solution will look like, I don't think we should start a repository: it would be bad if we have to abandon the repository of our approach changes (say we want to keep it tightly integrated inside Solr).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, 7 Jan, 2021, 11:45 pm Anshum Gupta, <[hidden email]> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi everyone,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Inline with my earlier email, I'll be requesting a new repository to host the cross-dc work. Please let me know if you have any questions or concerns.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Repository name: solr-crossdc
>>>>>>>>>>>>>>> Generated name: lucene-solr-crossdc.git (that's auto-generated, so can't remove the TLP prefix)
>>>>>>>>>>>>>>> Commit notification list: [hidden email] (I think it makes sense for these commit notifications to go to a new list, but I'm open to reusing the old one)
>>>>>>>>>>>>>>> GitHub notification list: [hidden email]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'll be submitting a request for the same later in the day today if there are no concerns.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Anshum Gupta
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Anshum Gupta
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Anshum Gupta
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Anshum Gupta
>>>
>>>
>>>
>>> --
>>> Anshum Gupta
>
>
>
> --
> Anshum Gupta



--
-----------------------------------------------------
Noble Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Requesting a new GH repository for CrossDC modules

Anshum Gupta
Building this as a branch is an option, but building it outside in a personal repo is exactly what's not the Apache Way.

Code should be designed and built in the Apache world, else it'd be a grant/donation and not really a PR. Also, you can't create a PR against a repo that doesn't exist upstream.

Do you have an objection against a mono-repo i.e. solr-sandbox too? That would open the door for us to use this for similar purposes in the future, until the code is ready to be released.

Also, just to reiterate, creating a repo doesn't cost anything and we aren't releasing anything. This is a placeholder to put the code in. If it works out well, we can release it or iterate on the code/implementation. In any case, it would have zero impact on the project itself.

-Anshum

On Tue, Jan 12, 2021 at 3:37 PM Noble Paul <[hidden email]> wrote:
I feel this is placing the cart before the horse.

We can always build this as a branch or a repo under your own account.
Once we reach a point where the project is reasonably mature, you can
create a repo and contribute it upstream.


On Wed, Jan 13, 2021 at 6:27 AM Anshum Gupta <[hidden email]> wrote:
>
> I understand what you are saying, which is also my reason to not have a mono-repo. This way it's easier to manage and drop a repository when it's not needed. It doesn't cause clutter and lives in isolation.
>
> I think we are on the same page in terms of the intention.
>
>
> On Tue, Jan 12, 2021 at 10:51 AM Ishan Chattopadhyaya <[hidden email]> wrote:
>>
>> Look at the branches that are cluttering up our main repository, many symbolic of unfinished work. If we start one repo each for everything we hope to finish, we'll make Solr annoying in a new way.
>>
>> There is no reason multiple artifacts can't be released independently from the same repo. Why are you opposed to that idea, Anshum?
>>
>> On Tue, 12 Jan, 2021, 11:53 pm Anshum Gupta, <[hidden email]> wrote:
>>>
>>> Thank you everyone!
>>>
>>> I'll move forward with the cross-dc repo creation then as mentioned in the original email :)
>>>
>>> If we want to change the approach on the repo, we can always change that before we release anything in the future.
>>>
>>> On Mon, Jan 11, 2021 at 10:32 AM Mike Drob <[hidden email]> wrote:
>>>>
>>>> I'm seeing valid reasons to prefer one solr sandbox repo, or prefer multiple many repos for future plugins or integrations. In this specific case, I think the relevant deciding points are 1) we don't have multiple things yet, so deciding between a "mono-repo" and a "multi-repo" is not very consequential 2) we can always rename things later 3) in the absence of a strong reason otherwise i'll defer to the people doing the work (in this case, Anshum). We considered sandbox and can always create one in the future. If Anshum feels that solr-cross-dc is better for now than I'm fine with that too.
>>>>
>>>> On Sun, Jan 10, 2021 at 5:07 PM David Smiley <[hidden email]> wrote:
>>>>>
>>>>> (palm-to-face) -- LOL okay sorry.  I'm getting my threads crossed.
>>>>>
>>>>> A repo which holds multiple independent modules that can work with Solr need not release them all at once.
>>>>>
>>>>> ~ David Smiley
>>>>> Apache Lucene/Solr Search Developer
>>>>> http://www.linkedin.com/in/davidwsmiley
>>>>>
>>>>>
>>>>> On Sat, Jan 9, 2021 at 4:48 PM Anshum Gupta <[hidden email]> wrote:
>>>>>>
>>>>>> David, this is about the Cross DC work that was supposed to be done :-)
>>>>>>
>>>>>> The independent release cadence is primarily the reason why a new repo makes sense to me in this case.
>>>>>>
>>>>>> On Sat, Jan 9, 2021 at 1:24 PM David Smiley <[hidden email]> wrote:
>>>>>>>
>>>>>>> While I like the idea of a single (Apache!) repo for multiple packages/plugins, that does not apply to the Solr Operator, which isn't even in Java.  It's too unique.  So I agree with Anshum & others about creating an Apache repo for the Solr Operator.
>>>>>>>
>>>>>>> I think the ship has sailed on the Solr Operator being an Apache project instead of some committer's pet project.
>>>>>>>
>>>>>>> ~ David Smiley
>>>>>>> Apache Lucene/Solr Search Developer
>>>>>>> http://www.linkedin.com/in/davidwsmiley
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jan 8, 2021 at 4:47 AM Ishan Chattopadhyaya <[hidden email]> wrote:
>>>>>>>>
>>>>>>>> Not necessarily. Most people contribute to Apache Lucene/Solr using external repositories (forks) and raise pull requests against Apache owned repositories. There's no SGA needed on such occasions.
>>>>>>>>
>>>>>>>> I see two paths forward from here.
>>>>>>>>
>>>>>>>> a) Lets setup a single repository for all packages/plugins, say lucene-solr-extras or lucene-solr-contribs or lucene-solr-sandbox etc., and develop it there.
>>>>>>>> b) All development for this effort happens in an external repository (https://github.com/apple/solr-dc or https://github.com/anshumg/solr-dc) and we raise a PR against Apache owned repository (which can be created if needed once we are all onboard).
>>>>>>>>
>>>>>>>> What does everyone else think?
>>>>>>>>
>>>>>>>> On Fri, Jan 8, 2021 at 10:23 AM Mike Drob <[hidden email]> wrote:
>>>>>>>>>
>>>>>>>>> An external repository probably ends up requiring a software grant? I know there is a material difference between code originating externally and code originating within the umbrella of the ASF in terms of IP, copyright, or other legal status.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Jan 7, 2021 at 8:11 PM Ishan Chattopadhyaya <[hidden email]> wrote:
>>>>>>>>>>
>>>>>>>>>> If all we need now is a place to commit a PoC for now (and something like sandbox repo or contribs won't suffice), why can't we have a separate repository in GitHub outside Apache and merge into an Apache repository only once the code takes reasonable shape?
>>>>>>>>>>
>>>>>>>>>> On Fri, 8 Jan, 2021, 2:31 am Anshum Gupta, <[hidden email]> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Thanks for the feedback, Mike.
>>>>>>>>>>>
>>>>>>>>>>> I like the idea of the sandbox, but that might be restricting when we want to work on more than one repos.
>>>>>>>>>>>
>>>>>>>>>>> I'm not sure if that would happen in the near future, but as we can always discard the repo and it doesn't really come at a cost, I don't see a problem with having a repo created for this specific reason.
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Jan 7, 2021 at 12:45 PM Mike Drob <[hidden email]> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> I'm not sure where I sit on this, going to start typing things and then hopefully I'll reach a conclusion by the end.
>>>>>>>>>>>>
>>>>>>>>>>>> This definitely needs to be outside of the core solr repo so that it can be versioned and released independently. And I disagree with Ishan about the consequence of abandoning the repository - if we realize that it's a bad direction then we can pivot, but we shouldn't let a fear of the unknown stop us from doing it in the first place.
>>>>>>>>>>>>
>>>>>>>>>>>> However, if all we need right now is a place to commit code that is WIP, then what we really want is a sandbox to play with, and not necessarily a strongly directed repo. Lucene has a sandbox in the main code. We could similarly start this under Solr contrib and move it out before an actual release of 9x happens. Or maybe we start with a [lucene-]solr-sandbox repository that we can throw all sorts of stuff into and then when components are mature enough they get to graduate into their own repo?
>>>>>>>>>>>>
>>>>>>>>>>>> Mike
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Jan 7, 2021 at 2:32 PM Anshum Gupta <[hidden email]> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> I understand your concern, but this is the placeholder for where the code would be, not what the code would look like.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Considering we agreed to do this in a repository outside of the core, I believe this is a good place to start. The idea that the release cadence for the cross-dc effort should be different from that of core is an argument in favor of this approach, but I'm happy to talk more about it.
>>>>>>>>>>>>> I just thought that based on the original email, folks were on-board with the idea of this being outside of core Solr artifact/release.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Jan 7, 2021 at 11:06 AM Ishan Chattopadhyaya <[hidden email]> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -1 on this. Without finalizing on the shape of how the solution will look like, I don't think we should start a repository: it would be bad if we have to abandon the repository of our approach changes (say we want to keep it tightly integrated inside Solr).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, 7 Jan, 2021, 11:45 pm Anshum Gupta, <[hidden email]> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi everyone,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Inline with my earlier email, I'll be requesting a new repository to host the cross-dc work. Please let me know if you have any questions or concerns.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Repository name: solr-crossdc
>>>>>>>>>>>>>>> Generated name: lucene-solr-crossdc.git (that's auto-generated, so can't remove the TLP prefix)
>>>>>>>>>>>>>>> Commit notification list: [hidden email] (I think it makes sense for these commit notifications to go to a new list, but I'm open to reusing the old one)
>>>>>>>>>>>>>>> GitHub notification list: [hidden email]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'll be submitting a request for the same later in the day today if there are no concerns.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Anshum Gupta
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Anshum Gupta
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Anshum Gupta
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Anshum Gupta
>>>
>>>
>>>
>>> --
>>> Anshum Gupta
>
>
>
> --
> Anshum Gupta



--
-----------------------------------------------------
Noble Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



--
Anshum Gupta
Reply | Threaded
Open this post in threaded view
|

Re: Requesting a new GH repository for CrossDC modules

Ishan Chattopadhyaya


On Wed, 13 Jan, 2021, 6:00 am Anshum Gupta, <[hidden email]> wrote:
Building this as a branch is an option, but building it outside in a personal repo is exactly what's not the Apache Way.

Negative. Nothing of that is mentioned in https://www.apache.org/theapacheway/. Private decision making isn't allowed, but discussions happening around code in an Apache communication channels (say ASF GitHub over a PR from a privately owned public repository) definitely seems The Apache Way.


Code should be designed and built in the Apache world, else it'd be a grant/donation and not really a PR.

An ICLA is just sufficient for that, a grant of copyright license of all code written by you to the ASF. You already filed the ICLA when you became a committer. 

Also, you can't create a PR against a repo that doesn't exist upstream.

You should create the PR against an existing branch and demonstrate that the code is at least functioning and we can consider a separate repository at that point.

David's blobstore work is an example of this. Jason's incremental backup work another example (base code is in lucene-solr repo of lucidworks' fork as a PR by Shalin). Both know such code may or may not continue to reside in lucene-solr repo, but are working on building consensus and building a working prototype first, not discussing the release cycle and the final location of the code.


Do you have an objection against a mono-repo i.e. solr-sandbox too? That would open the door for us to use this for similar purposes in the future, until the code is ready to be released.

Also, just to reiterate, creating a repo doesn't cost anything and we aren't releasing anything.

It costs the headache of dealing with stubborn actors who may oppose deletion of the repo if it is decided that it is not the right solution. Just look at deprecation of original CDCR from Solr as an example, where you and some others came across as a shining stars of such opposition, despite knowing it was deeply broken and not offering any help to fix it.

This is a placeholder to put the code in. If it works out well, we can release it or iterate on the code/implementation. In any case, it would have zero impact on the project itself.

I disagree on zero impact to project. It causes reputational damage if not done properly, and in your case here, the work  hasn't even started yet.


-Anshum

On Tue, Jan 12, 2021 at 3:37 PM Noble Paul <[hidden email]> wrote:
I feel this is placing the cart before the horse.

We can always build this as a branch or a repo under your own account.
Once we reach a point where the project is reasonably mature, you can
create a repo and contribute it upstream.


On Wed, Jan 13, 2021 at 6:27 AM Anshum Gupta <[hidden email]> wrote:
>
> I understand what you are saying, which is also my reason to not have a mono-repo. This way it's easier to manage and drop a repository when it's not needed. It doesn't cause clutter and lives in isolation.
>
> I think we are on the same page in terms of the intention.
>
>
> On Tue, Jan 12, 2021 at 10:51 AM Ishan Chattopadhyaya <[hidden email]> wrote:
>>
>> Look at the branches that are cluttering up our main repository, many symbolic of unfinished work. If we start one repo each for everything we hope to finish, we'll make Solr annoying in a new way.
>>
>> There is no reason multiple artifacts can't be released independently from the same repo. Why are you opposed to that idea, Anshum?
>>
>> On Tue, 12 Jan, 2021, 11:53 pm Anshum Gupta, <[hidden email]> wrote:
>>>
>>> Thank you everyone!
>>>
>>> I'll move forward with the cross-dc repo creation then as mentioned in the original email :)
>>>
>>> If we want to change the approach on the repo, we can always change that before we release anything in the future.
>>>
>>> On Mon, Jan 11, 2021 at 10:32 AM Mike Drob <[hidden email]> wrote:
>>>>
>>>> I'm seeing valid reasons to prefer one solr sandbox repo, or prefer multiple many repos for future plugins or integrations. In this specific case, I think the relevant deciding points are 1) we don't have multiple things yet, so deciding between a "mono-repo" and a "multi-repo" is not very consequential 2) we can always rename things later 3) in the absence of a strong reason otherwise i'll defer to the people doing the work (in this case, Anshum). We considered sandbox and can always create one in the future. If Anshum feels that solr-cross-dc is better for now than I'm fine with that too.
>>>>
>>>> On Sun, Jan 10, 2021 at 5:07 PM David Smiley <[hidden email]> wrote:
>>>>>
>>>>> (palm-to-face) -- LOL okay sorry.  I'm getting my threads crossed.
>>>>>
>>>>> A repo which holds multiple independent modules that can work with Solr need not release them all at once.
>>>>>
>>>>> ~ David Smiley
>>>>> Apache Lucene/Solr Search Developer
>>>>> http://www.linkedin.com/in/davidwsmiley
>>>>>
>>>>>
>>>>> On Sat, Jan 9, 2021 at 4:48 PM Anshum Gupta <[hidden email]> wrote:
>>>>>>
>>>>>> David, this is about the Cross DC work that was supposed to be done :-)
>>>>>>
>>>>>> The independent release cadence is primarily the reason why a new repo makes sense to me in this case.
>>>>>>
>>>>>> On Sat, Jan 9, 2021 at 1:24 PM David Smiley <[hidden email]> wrote:
>>>>>>>
>>>>>>> While I like the idea of a single (Apache!) repo for multiple packages/plugins, that does not apply to the Solr Operator, which isn't even in Java.  It's too unique.  So I agree with Anshum & others about creating an Apache repo for the Solr Operator.
>>>>>>>
>>>>>>> I think the ship has sailed on the Solr Operator being an Apache project instead of some committer's pet project.
>>>>>>>
>>>>>>> ~ David Smiley
>>>>>>> Apache Lucene/Solr Search Developer
>>>>>>> http://www.linkedin.com/in/davidwsmiley
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jan 8, 2021 at 4:47 AM Ishan Chattopadhyaya <[hidden email]> wrote:
>>>>>>>>
>>>>>>>> Not necessarily. Most people contribute to Apache Lucene/Solr using external repositories (forks) and raise pull requests against Apache owned repositories. There's no SGA needed on such occasions.
>>>>>>>>
>>>>>>>> I see two paths forward from here.
>>>>>>>>
>>>>>>>> a) Lets setup a single repository for all packages/plugins, say lucene-solr-extras or lucene-solr-contribs or lucene-solr-sandbox etc., and develop it there.
>>>>>>>> b) All development for this effort happens in an external repository (https://github.com/apple/solr-dc or https://github.com/anshumg/solr-dc) and we raise a PR against Apache owned repository (which can be created if needed once we are all onboard).
>>>>>>>>
>>>>>>>> What does everyone else think?
>>>>>>>>
>>>>>>>> On Fri, Jan 8, 2021 at 10:23 AM Mike Drob <[hidden email]> wrote:
>>>>>>>>>
>>>>>>>>> An external repository probably ends up requiring a software grant? I know there is a material difference between code originating externally and code originating within the umbrella of the ASF in terms of IP, copyright, or other legal status.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Jan 7, 2021 at 8:11 PM Ishan Chattopadhyaya <[hidden email]> wrote:
>>>>>>>>>>
>>>>>>>>>> If all we need now is a place to commit a PoC for now (and something like sandbox repo or contribs won't suffice), why can't we have a separate repository in GitHub outside Apache and merge into an Apache repository only once the code takes reasonable shape?
>>>>>>>>>>
>>>>>>>>>> On Fri, 8 Jan, 2021, 2:31 am Anshum Gupta, <[hidden email]> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Thanks for the feedback, Mike.
>>>>>>>>>>>
>>>>>>>>>>> I like the idea of the sandbox, but that might be restricting when we want to work on more than one repos.
>>>>>>>>>>>
>>>>>>>>>>> I'm not sure if that would happen in the near future, but as we can always discard the repo and it doesn't really come at a cost, I don't see a problem with having a repo created for this specific reason.
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Jan 7, 2021 at 12:45 PM Mike Drob <[hidden email]> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> I'm not sure where I sit on this, going to start typing things and then hopefully I'll reach a conclusion by the end.
>>>>>>>>>>>>
>>>>>>>>>>>> This definitely needs to be outside of the core solr repo so that it can be versioned and released independently. And I disagree with Ishan about the consequence of abandoning the repository - if we realize that it's a bad direction then we can pivot, but we shouldn't let a fear of the unknown stop us from doing it in the first place.
>>>>>>>>>>>>
>>>>>>>>>>>> However, if all we need right now is a place to commit code that is WIP, then what we really want is a sandbox to play with, and not necessarily a strongly directed repo. Lucene has a sandbox in the main code. We could similarly start this under Solr contrib and move it out before an actual release of 9x happens. Or maybe we start with a [lucene-]solr-sandbox repository that we can throw all sorts of stuff into and then when components are mature enough they get to graduate into their own repo?
>>>>>>>>>>>>
>>>>>>>>>>>> Mike
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Jan 7, 2021 at 2:32 PM Anshum Gupta <[hidden email]> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> I understand your concern, but this is the placeholder for where the code would be, not what the code would look like.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Considering we agreed to do this in a repository outside of the core, I believe this is a good place to start. The idea that the release cadence for the cross-dc effort should be different from that of core is an argument in favor of this approach, but I'm happy to talk more about it.
>>>>>>>>>>>>> I just thought that based on the original email, folks were on-board with the idea of this being outside of core Solr artifact/release.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Jan 7, 2021 at 11:06 AM Ishan Chattopadhyaya <[hidden email]> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -1 on this. Without finalizing on the shape of how the solution will look like, I don't think we should start a repository: it would be bad if we have to abandon the repository of our approach changes (say we want to keep it tightly integrated inside Solr).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, 7 Jan, 2021, 11:45 pm Anshum Gupta, <[hidden email]> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi everyone,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Inline with my earlier email, I'll be requesting a new repository to host the cross-dc work. Please let me know if you have any questions or concerns.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Repository name: solr-crossdc
>>>>>>>>>>>>>>> Generated name: lucene-solr-crossdc.git (that's auto-generated, so can't remove the TLP prefix)
>>>>>>>>>>>>>>> Commit notification list: [hidden email] (I think it makes sense for these commit notifications to go to a new list, but I'm open to reusing the old one)
>>>>>>>>>>>>>>> GitHub notification list: [hidden email]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'll be submitting a request for the same later in the day today if there are no concerns.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Anshum Gupta
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Anshum Gupta
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Anshum Gupta
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Anshum Gupta
>>>
>>>
>>>
>>> --
>>> Anshum Gupta
>
>
>
> --
> Anshum Gupta



--
-----------------------------------------------------
Noble Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



--
Anshum Gupta
Reply | Threaded
Open this post in threaded view
|

Re: Requesting a new GH repository for CrossDC modules

Noble Paul നോബിള്‍  नोब्ळ्
In reply to this post by Anshum Gupta
I'm +1 for a  top level sandbox repo. Anyone should be able create a project in that. 

Once the project graduates out of the sandbox we should create a top level

On Wed, Jan 13, 2021, 11:30 AM Anshum Gupta <[hidden email]> wrote:
Building this as a branch is an option, but building it outside in a personal repo is exactly what's not the Apache Way.

Code should be designed and built in the Apache world, else it'd be a grant/donation and not really a PR. Also, you can't create a PR against a repo that doesn't exist upstream.

Do you have an objection against a mono-repo i.e. solr-sandbox too? That would open the door for us to use this for similar purposes in the future, until the code is ready to be released.

Also, just to reiterate, creating a repo doesn't cost anything and we aren't releasing anything. This is a placeholder to put the code in. If it works out well, we can release it or iterate on the code/implementation. In any case, it would have zero impact on the project itself.

-Anshum

On Tue, Jan 12, 2021 at 3:37 PM Noble Paul <[hidden email]> wrote:
I feel this is placing the cart before the horse.

We can always build this as a branch or a repo under your own account.
Once we reach a point where the project is reasonably mature, you can
create a repo and contribute it upstream.


On Wed, Jan 13, 2021 at 6:27 AM Anshum Gupta <[hidden email]> wrote:
>
> I understand what you are saying, which is also my reason to not have a mono-repo. This way it's easier to manage and drop a repository when it's not needed. It doesn't cause clutter and lives in isolation.
>
> I think we are on the same page in terms of the intention.
>
>
> On Tue, Jan 12, 2021 at 10:51 AM Ishan Chattopadhyaya <[hidden email]> wrote:
>>
>> Look at the branches that are cluttering up our main repository, many symbolic of unfinished work. If we start one repo each for everything we hope to finish, we'll make Solr annoying in a new way.
>>
>> There is no reason multiple artifacts can't be released independently from the same repo. Why are you opposed to that idea, Anshum?
>>
>> On Tue, 12 Jan, 2021, 11:53 pm Anshum Gupta, <[hidden email]> wrote:
>>>
>>> Thank you everyone!
>>>
>>> I'll move forward with the cross-dc repo creation then as mentioned in the original email :)
>>>
>>> If we want to change the approach on the repo, we can always change that before we release anything in the future.
>>>
>>> On Mon, Jan 11, 2021 at 10:32 AM Mike Drob <[hidden email]> wrote:
>>>>
>>>> I'm seeing valid reasons to prefer one solr sandbox repo, or prefer multiple many repos for future plugins or integrations. In this specific case, I think the relevant deciding points are 1) we don't have multiple things yet, so deciding between a "mono-repo" and a "multi-repo" is not very consequential 2) we can always rename things later 3) in the absence of a strong reason otherwise i'll defer to the people doing the work (in this case, Anshum). We considered sandbox and can always create one in the future. If Anshum feels that solr-cross-dc is better for now than I'm fine with that too.
>>>>
>>>> On Sun, Jan 10, 2021 at 5:07 PM David Smiley <[hidden email]> wrote:
>>>>>
>>>>> (palm-to-face) -- LOL okay sorry.  I'm getting my threads crossed.
>>>>>
>>>>> A repo which holds multiple independent modules that can work with Solr need not release them all at once.
>>>>>
>>>>> ~ David Smiley
>>>>> Apache Lucene/Solr Search Developer
>>>>> http://www.linkedin.com/in/davidwsmiley
>>>>>
>>>>>
>>>>> On Sat, Jan 9, 2021 at 4:48 PM Anshum Gupta <[hidden email]> wrote:
>>>>>>
>>>>>> David, this is about the Cross DC work that was supposed to be done :-)
>>>>>>
>>>>>> The independent release cadence is primarily the reason why a new repo makes sense to me in this case.
>>>>>>
>>>>>> On Sat, Jan 9, 2021 at 1:24 PM David Smiley <[hidden email]> wrote:
>>>>>>>
>>>>>>> While I like the idea of a single (Apache!) repo for multiple packages/plugins, that does not apply to the Solr Operator, which isn't even in Java.  It's too unique.  So I agree with Anshum & others about creating an Apache repo for the Solr Operator.
>>>>>>>
>>>>>>> I think the ship has sailed on the Solr Operator being an Apache project instead of some committer's pet project.
>>>>>>>
>>>>>>> ~ David Smiley
>>>>>>> Apache Lucene/Solr Search Developer
>>>>>>> http://www.linkedin.com/in/davidwsmiley
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jan 8, 2021 at 4:47 AM Ishan Chattopadhyaya <[hidden email]> wrote:
>>>>>>>>
>>>>>>>> Not necessarily. Most people contribute to Apache Lucene/Solr using external repositories (forks) and raise pull requests against Apache owned repositories. There's no SGA needed on such occasions.
>>>>>>>>
>>>>>>>> I see two paths forward from here.
>>>>>>>>
>>>>>>>> a) Lets setup a single repository for all packages/plugins, say lucene-solr-extras or lucene-solr-contribs or lucene-solr-sandbox etc., and develop it there.
>>>>>>>> b) All development for this effort happens in an external repository (https://github.com/apple/solr-dc or https://github.com/anshumg/solr-dc) and we raise a PR against Apache owned repository (which can be created if needed once we are all onboard).
>>>>>>>>
>>>>>>>> What does everyone else think?
>>>>>>>>
>>>>>>>> On Fri, Jan 8, 2021 at 10:23 AM Mike Drob <[hidden email]> wrote:
>>>>>>>>>
>>>>>>>>> An external repository probably ends up requiring a software grant? I know there is a material difference between code originating externally and code originating within the umbrella of the ASF in terms of IP, copyright, or other legal status.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Jan 7, 2021 at 8:11 PM Ishan Chattopadhyaya <[hidden email]> wrote:
>>>>>>>>>>
>>>>>>>>>> If all we need now is a place to commit a PoC for now (and something like sandbox repo or contribs won't suffice), why can't we have a separate repository in GitHub outside Apache and merge into an Apache repository only once the code takes reasonable shape?
>>>>>>>>>>
>>>>>>>>>> On Fri, 8 Jan, 2021, 2:31 am Anshum Gupta, <[hidden email]> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Thanks for the feedback, Mike.
>>>>>>>>>>>
>>>>>>>>>>> I like the idea of the sandbox, but that might be restricting when we want to work on more than one repos.
>>>>>>>>>>>
>>>>>>>>>>> I'm not sure if that would happen in the near future, but as we can always discard the repo and it doesn't really come at a cost, I don't see a problem with having a repo created for this specific reason.
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Jan 7, 2021 at 12:45 PM Mike Drob <[hidden email]> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> I'm not sure where I sit on this, going to start typing things and then hopefully I'll reach a conclusion by the end.
>>>>>>>>>>>>
>>>>>>>>>>>> This definitely needs to be outside of the core solr repo so that it can be versioned and released independently. And I disagree with Ishan about the consequence of abandoning the repository - if we realize that it's a bad direction then we can pivot, but we shouldn't let a fear of the unknown stop us from doing it in the first place.
>>>>>>>>>>>>
>>>>>>>>>>>> However, if all we need right now is a place to commit code that is WIP, then what we really want is a sandbox to play with, and not necessarily a strongly directed repo. Lucene has a sandbox in the main code. We could similarly start this under Solr contrib and move it out before an actual release of 9x happens. Or maybe we start with a [lucene-]solr-sandbox repository that we can throw all sorts of stuff into and then when components are mature enough they get to graduate into their own repo?
>>>>>>>>>>>>
>>>>>>>>>>>> Mike
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Jan 7, 2021 at 2:32 PM Anshum Gupta <[hidden email]> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> I understand your concern, but this is the placeholder for where the code would be, not what the code would look like.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Considering we agreed to do this in a repository outside of the core, I believe this is a good place to start. The idea that the release cadence for the cross-dc effort should be different from that of core is an argument in favor of this approach, but I'm happy to talk more about it.
>>>>>>>>>>>>> I just thought that based on the original email, folks were on-board with the idea of this being outside of core Solr artifact/release.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Jan 7, 2021 at 11:06 AM Ishan Chattopadhyaya <[hidden email]> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -1 on this. Without finalizing on the shape of how the solution will look like, I don't think we should start a repository: it would be bad if we have to abandon the repository of our approach changes (say we want to keep it tightly integrated inside Solr).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, 7 Jan, 2021, 11:45 pm Anshum Gupta, <[hidden email]> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi everyone,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Inline with my earlier email, I'll be requesting a new repository to host the cross-dc work. Please let me know if you have any questions or concerns.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Repository name: solr-crossdc
>>>>>>>>>>>>>>> Generated name: lucene-solr-crossdc.git (that's auto-generated, so can't remove the TLP prefix)
>>>>>>>>>>>>>>> Commit notification list: [hidden email] (I think it makes sense for these commit notifications to go to a new list, but I'm open to reusing the old one)
>>>>>>>>>>>>>>> GitHub notification list: [hidden email]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'll be submitting a request for the same later in the day today if there are no concerns.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Anshum Gupta
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Anshum Gupta
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Anshum Gupta
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Anshum Gupta
>>>
>>>
>>>
>>> --
>>> Anshum Gupta
>
>
>
> --
> Anshum Gupta



--
-----------------------------------------------------
Noble Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



--
Anshum Gupta
12