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 <dsmi...@apache.org> 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 < > ichattopadhy...@gmail.com> 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 <md...@apache.org> 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 < >>> ichattopadhy...@gmail.com> 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, <ans...@anshumgupta.net> >>>> 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 <md...@apache.org> 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 <ans...@anshumgupta.net> >>>>>> 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 < >>>>>>> ichattopadhy...@gmail.com> 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, <ans...@anshumgupta.net> >>>>>>>> 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:* commits-cros...@lucene.apache.org (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:* dev@lucene.apache.org >>>>>>>>> >>>>>>>>> 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
