(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 <[email protected]> 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 <[email protected]> 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 < >> [email protected]> 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 <[email protected]> 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 < >>>> [email protected]> 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, <[email protected]> >>>>> 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 <[email protected]> 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 <[email protected]> >>>>>>> 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 < >>>>>>>> [email protected]> 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, < >>>>>>>>> [email protected]> 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:* [email protected] (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:* [email protected] >>>>>>>>>> >>>>>>>>>> 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 >
