The question is whether branch_8x work would happen in lucene.git or in lucene-solr.git? Perhaps lucene-solr.git is most logical. Dawid?
Jan > 9. mar. 2021 kl. 21:02 skrev David Smiley <dsmi...@apache.org>: > > Thanks Jan! > > I thought I saw in this thread something about the lucene-solr repo becoming > read-only? I imagine it would be a good thing to continue discussions on > PRs, even if to simply add a URL pointing to follow-up PRs. And we'll need > to make commits to branch_8x and previous branches for future releases (e.g. > for a vulnerability). > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > <http://www.linkedin.com/in/davidwsmiley> > > On Mon, Mar 8, 2021 at 6:58 PM Jan Høydahl <jan....@cominvent.com > <mailto:jan....@cominvent.com>> wrote: > Made a branch in my normal repo: > https://github.com/cominvent/lucene-solr/tree/silly-pr > <https://github.com/cominvent/lucene-solr/tree/silly-pr> and spun it up as a > PR against your solr-only test repo > https://github.com/dsmiley/lucene-solr/pull/1 > <https://github.com/dsmiley/lucene-solr/pull/1> > Looks like this won't be a problem :) > > I imagine a documentation like this HOWTO I created in the Solr Wiki: > https://cwiki.apache.org/confluence/display/SOLR/Move+your+PR+to+the+new+Solr+GitHub+repo > > <https://cwiki.apache.org/confluence/display/SOLR/Move+your+PR+to+the+new+Solr+GitHub+repo> > > > Jan > >> 8. mar. 2021 kl. 20:15 skrev David Smiley <dsmi...@apache.org >> <mailto:dsmi...@apache.org>>: >> >> Answering my own question -- apparently Solr on master now depends on >> snapshot builds of Lucene published by ASF Nexus: >> https://issues.apache.org/jira/browse/SOLR-14759 >> <https://issues.apache.org/jira/browse/SOLR-14759> >> Cool! >> >> About PRs: Someone should experiment here to see what's involved before the >> split. To get this started, I pushed a "solr_main" branch to my GitHub Solr >> fork. All I did was create a branch off of master, then remove Lucene and >> commit & pushed that. Someone, please try to take one of your existing PRs >> and send it to my fork against solr_main to see how that goes? This needs >> to be figured out before the split so we all have guidance on how to do this >> without all of us trying to redundantly figure it out at the same time. >> >> ~ David Smiley >> Apache Lucene/Solr Search Developer >> http://www.linkedin.com/in/davidwsmiley >> <http://www.linkedin.com/in/davidwsmiley> >> >> On Mon, Mar 8, 2021 at 1:43 PM David Smiley <dsmi...@apache.org >> <mailto:dsmi...@apache.org>> wrote: >> One of us will get there first and should share. For my part, I intend to >> add a new remote, pull the branches from it, then use "git worktree" to add >> a new local work tree alongside my existing ones (for lucene_solr master, >> lucene_solr branch_8x). I call my current remote "apache" but I might first >> rename it to "apache_pre9". I am not yet sure if I will use another worktree >> for the new Lucene repo or if I'll do a new clone. >> >> I think there's a case to be made for the Lucene repo to rewrite history to >> remove Solr. >> >> ~ David Smiley >> Apache Lucene/Solr Search Developer >> http://www.linkedin.com/in/davidwsmiley >> <http://www.linkedin.com/in/davidwsmiley> >> >> On Mon, Mar 8, 2021 at 1:24 PM Mike Drob <md...@mdrob.com >> <mailto:md...@mdrob.com>> wrote: >> Can we provide a sequence of git commands for folks to run? Or will the >> official guidance be to create new local clones of each repo? >> >> On Mon, Mar 8, 2021 at 12:18 PM David Smiley <dsmi...@apache.org >> <mailto:dsmi...@apache.org>> wrote: >> Yeah, I agree with Jan -- don't rename the GitHub repo. It's going to be >> painful no matter what and a rename doesn't seem appropriate. >> >> I am curious as to the status of /solr code being buildable without /lucene. >> The steps above at #2 say for each project to remove the other side. Is >> Solr ready? Where will Solr get the Lucene binaries? >> >> ~ David Smiley >> Apache Lucene/Solr Search Developer >> http://www.linkedin.com/in/davidwsmiley >> <http://www.linkedin.com/in/davidwsmiley> >> >> On Mon, Mar 8, 2021 at 12:53 PM Jan Høydahl <jan....@cominvent.com >> <mailto:jan....@cominvent.com>> wrote: >> Hi, >> >> There are 324 open PRs. Some numbers: >> Number updated last month: 40 >> Number not touched last 4 months: 249 (77%) >> With LUCENE in title: 93 >> With SOLR in title: 181 >> >> It would be nice to auto migrate but some times you just have to face >> changes and do some extra work :) >> Given how easy it is to create a new PR in the new repo based on the >> existing PR branch, I say we just clearly document how to do it, and let the >> ~50 PRs that are actually being worked on be re-created. PR author can add a >> link to the old one to reference review comments that cannot be carried over. >> >> It would be misleading to just rename to either solr or lucene. Much better >> to leave old repo there with a README notice that people need to clone the >> new repo(s) or update their remotes. >> >> Jan >> >> >> > 8. mar. 2021 kl. 17:21 skrev Uwe Schindler <u...@thetaphi.de >> > <mailto:u...@thetaphi.de>>: >> > >> > Hi again, >> > >> > we can maybe "improve" the situation a bit: On Github you can (with >> > Admin/Ownership rights) rename a project. So my suggestion: >> > >> > - Check pull requests and count how many affect solr and how many affect >> > Lucene. >> > - In cooperation with Infra rename the Github project >> > ("apache/lucene-solr.git") to "apache/lucene.git" (if more pull requests >> > affect Lucene) or "apache/solr.git" (if more are Solr). The PRs will >> > survive the rename. Also the old GitHub URL will redirect to the renamed >> > one. The other project should be created as a fork - of course without PRs. >> > >> > We can only do this in cooperation with Apache Infra stuff, because we >> > can' change the Github repo settings or rename them using the Github UI. >> > >> > Uwe >> > >> > ----- >> > Uwe Schindler >> > Achterdiek 19, D-28357 Bremen >> > https://www.thetaphi.de <https://www.thetaphi.de/> >> > eMail: u...@thetaphi.de <mailto:u...@thetaphi.de> >> > >> >> -----Original Message----- >> >> From: Uwe Schindler <u...@thetaphi.de <mailto:u...@thetaphi.de>> >> >> Sent: Monday, March 8, 2021 5:16 PM >> >> To: dev@lucene.apache.org <mailto:dev@lucene.apache.org> >> >> Subject: RE: Repository fork (master) about to happen (Wednesday) >> >> >> >> I think the problem was what happens with the PR in Githubs user >> >> interface. >> >> >> >> This question was asked many times, answer is simple: NO you can't move >> >> over >> >> Pull requests to different repositories on Github! It's also impossible >> >> to export >> >> and reimport them. People have to recreate them. >> >> >> >> Dawid is correct: You can merge the pull request also into another rlocal >> >> repository, but this is impossible with the Github UI. So basically, you >> >> have to >> >> read the email that comes in with the Pull Request that lists the link to >> >> the >> >> branch and patch. Then use git command line (or Tortoise) and copypaste >> >> the >> >> URL there as "source branch" for the merge. Then you execute the merge, >> >> squash and commit/push. >> >> >> >> Uwe >> >> >> >> ----- >> >> Uwe Schindler >> >> Achterdiek 19, D-28357 Bremen >> >> https://www.thetaphi.de <https://www.thetaphi.de/> >> >> eMail: u...@thetaphi.de <mailto:u...@thetaphi.de> >> >> >> >>> -----Original Message----- >> >>> From: Dawid Weiss <dawid.we...@gmail.com <mailto:dawid.we...@gmail.com>> >> >>> Sent: Monday, March 8, 2021 3:25 PM >> >>> To: Lucene Dev <dev@lucene.apache.org <mailto:dev@lucene.apache.org>> >> >>> Subject: Re: Repository fork (master) about to happen (Wednesday) >> >>> >> >>>> What happens to open PRs? >> >>> >> >>> A pull request on github is essentially a diff between two commits. >> >>> Existing PRs have to be placed on top of the new development branch. >> >>> Note these repositories are (initially) identical with lucene-solr so >> >>> if somebody clones the solr repo and the solr-lucene repo, they can >> >>> create the same PR over at the new project (pointing at the new main >> >>> branch as a reference). >> >>> >> >>> Dawid >> >>> >> >>> --------------------------------------------------------------------- >> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> >>> <mailto:dev-unsubscr...@lucene.apache.org> >> >>> For additional commands, e-mail: dev-h...@lucene.apache.org >> >>> <mailto:dev-h...@lucene.apache.org> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> >> <mailto:dev-unsubscr...@lucene.apache.org> >> >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> <mailto:dev-h...@lucene.apache.org> >> > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> > <mailto:dev-unsubscr...@lucene.apache.org> >> > For additional commands, e-mail: dev-h...@lucene.apache.org >> > <mailto:dev-h...@lucene.apache.org> >> > >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> <mailto:dev-unsubscr...@lucene.apache.org> >> For additional commands, e-mail: dev-h...@lucene.apache.org >> <mailto:dev-h...@lucene.apache.org> >> >
