Re: [DISCUSS] A proposal for migration to GitHub issue (LUCENE-10557)

Thanks everyone for your thoughtful comments - I think we can learn a lot from Solr Operator project. And then, I'd appreciate the feedback from Julie; not only because of the support for the migration but also because we surely need feedback from committers/contributors who actively create or

Re: [DISCUSS] A proposal for migration to GitHub issue (LUCENE-10557)

I don't have much to add to the (already very detailed!) discussion, just wanted to add my support for the idea of moving to GitHub. I've had a good experience with GitHub issues for other repos I contribute to and find the mark-up language comfortable and expressive. I also think switching to

Re: [DISCUSS] A proposal for migration to GitHub issue (LUCENE-10557)

I'm not going to get into how the Github automation should be done, that's a whole separate thread. But I agree too much automation can certainly be annoying and a burden. You can see this a lot in the kubernetes repos ( https://github.com/kubernetes), though it does come with its reasons.

Re: [DISCUSS] A proposal for migration to GitHub issue (LUCENE-10557)

I recommend people take a look at the now deprecated helm project. It was very difficult to land PRs because they had so much governance and automation. For a data store as mature as SOLR, I would suggest it is needed. Many issues are worth a read: https://github.com/helm/helm On Tue, May 10,

Re: [DISCUSS] A proposal for migration to GitHub issue (LUCENE-10557)

On Tue, May 10, 2022 at 10:40 AM Houston Putman wrote: > >> > Most modern open source projects use Github Issues for their issue > tracking, so it's definitely doable, and really what new > users/contributors will be expecting. Also I see that much discussion is > already done on PRs, and JIRAs

Re: [DISCUSS] A proposal for migration to GitHub issue (LUCENE-10557)

Yes, the listing of differences (that we rely on) of course has two resolution paths to facilitate such a move. A) find a way to fill the gap B) decide we don't care about the gap - either is fine so long as it's an intentional decision, not an oops we discover and regret later. On Tue, May 10,

Re: [DISCUSS] A proposal for migration to GitHub issue (LUCENE-10557)

> > It's not about features, but about accepting a new framework to me. GitHub > issue would not be a replacement Jira, and we cannot operate this project > on GitHub issue in the same way on Jira. We'd need to build our new > convention and operations on the new toolkit. > I think this is a very

Re: Lucene 9.2 release

Hi Mayya, Yes, that’s fine. I will hold off until you have merged those two PRs. - Alan > On 10 May 2022, at 14:24, Mayya Sharipova > wrote: > > Hi Alan, > we have PRs (870 , 872 >

Re: Lucene 9.2 release

Hi Alan, we have PRs (870 , 872 ) in progress that involve format changes to vectors. We would like to merge them for 9.2. Would it be possible to wait for a couple of days for the branch cut? I can update here

Re: [DISCUSS] A proposal for migration to GitHub issue (LUCENE-10557)

Thanks Alessandro for openly sharing your perspective! > I have limited experience with the Github issue system, it looks definitely "simpler" than Jira, not sure it covers all our requirements. I feel I'd need to explain my thoughts on this point. Yes, I think I know very well about such kind

Re: [DISCUSS] A proposal for migration to GitHub issue (LUCENE-10557)

Hi Tomoko, thanks for raising this! I am always in favor of simplicity and with the idea that code should speak for itself(readable code and meaningful commit messages over dirty code covered by a detailed Jira issue). Now, given that, I have been using Jira for many years, I agree with all the