On Wed, 13 Jan, 2021, 6:00 am Anshum Gupta, <anshum@anshumgupta.net> 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 <noble.paul@gmail.com> 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 <anshum@anshumgupta.net>
>> 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 <
>> ichattopadhyaya@gmail.com> 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, <anshum@anshumgupta.net>
>> 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 <mdrob@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 <dsmiley@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 <anshum@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 <dsmiley@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 <
>> ichattopadhyaya@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 <mdrob@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 <
>> ichattopadhyaya@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, <
>> anshum@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 <mdrob@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 <
>> anshum@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 <
>> ichattopadhyaya@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, <
>> anshum@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-crossdc@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
>> >
>> >
>> >
>> > --
>> > Anshum Gupta
>>
>>
>>
>> --
>> -----------------------------------------------------
>> Noble Paul
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>
> --
> Anshum Gupta
>