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 <md...@apache.org> 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 <dsmi...@apache.org> 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 <ans...@anshumgupta.net>
>> 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 <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
>>>
>>

-- 
Anshum Gupta

Reply via email to