> > But big +1 on ensuring we can always recover all of our (future) GitHub > issues + metadata in the future event where we suddenly decide to move to > something else. This should not be a one-way door, and as part of the VOTE > process, we should do our best to confirm this. > > This caused me to think about something.. issues -> issues on the way in issues -> issues on the way out, but what happens to PR's on the way out? This would sort of mean that the only systems we could move to in the future are systems to which we can migrate PRs?
Another thing to think about is branch cleanup vs PR's if the discussion is in PR's we need to keep all the branches? (which I generally favor in the first place, but I've seen folks want to clean up old branches) > I also feel it is vital we are able to migrate our full Jira issue history > to GitHub issues. Dawid's (herculean) efforts to preserve our full > Subversion history on moving to git was incredible and really vital. To > this day, you can "git log" and at the very bottom you see the first few > Lucene commits (under Apache Jakarta from 2001, on migrating from > SourceForge)! Lucene is a unique open-source project, with SO much > history, still so vibrant after so much time, surviving crazy JVM/JDK bugs, > and its widespread and growing adoption now. We must preserve that > history: it is a vital part of Lucene's current appeal and growth. Those > who do not study history are doomed to repeat it! We should not > intentionally throw our history away. So I will (most likely) VOTE -1 if > we cannot preserve our detailed Jira issue history on migration, and > likewise if we cannot do so (based on our best prediction) in the future on > migration from GitHub issues to elsewhere. > Yes history is super important, and actually I have (prior to this discussion) worried that the use of PR's in our current state has made the history/discussion a little harder to understand, but line focused comments are obviously also super good, so I've felt conflicted there. > > Mike McCandless > > http://blog.mikemccandless.com > > > On Wed, May 11, 2022 at 12:58 AM Tomoko Uchida < > [email protected]> wrote: > >> 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 review patches/PRs on a >> regular basis and drives this project like you. >> Of course, advisory comments from the whole community are really helpful >> and I welcome feedback from all developers, regardless of the activities on >> Lucene. >> >> I don't think I'm good at facilitation, I'll try to be here though :) >> I hope we'll continue a good conversation, and then, we can be confident >> opening the official vote. >> >> Tomoko >> >> >> 2022年5月11日(水) 9:36 Julie Tibshirani <[email protected]>: >> >>> 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 >>> GitHub could help newer contributors engage with the project. When I first >>> started contributing I found it really hard to navigate and search JIRA for >>> issues I was interested in. Now I rely on Mike's wonderful JIRA search tool >>> (https://jirasearch.mikemccandless.com/search.py), but most new >>> contributors do not know about it (and it adds another dependency on top of >>> GitHub and JIRA). >>> >>> Julie >>> >>> On Tue, May 10, 2022 at 12:41 PM Houston Putman <[email protected]> >>> wrote: >>> >>>> 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. >>>> >>>> Kubernetes is a good example of a project MUCH bigger than Solr >>>> successfully using Github Issues & PRs. So I don't really think it's a >>>> question if Github is feature-rich enough to handle our use case, it's >>>> pretty clear that it is. It will certainly be a change in process, but I >>>> think that all of these very successful open source projects show that it's >>>> a valid option for our projects. I think the ultimate questions are: >>>> >>>> - Which will be easier for users to find relevant information? >>>> - Which reduces the amount of bureaucracy needed to contribute to >>>> the project? >>>> - Which fits into the workflows of existing committers the best? >>>> >>>> To me Github comes up on top, even though there are things that JIRA >>>> does better. >>>> >>>> P.S. I think you mean https://github.com/helm/charts, marcus. I don't >>>> think helm is deprecated >>>> >>>> On Tue, May 10, 2022 at 1:41 PM Marcus Eagan <[email protected]> >>>> wrote: >>>> >>>>> 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, 2022 at 10:16 AM Gus Heck <[email protected]> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Tue, May 10, 2022 at 10:40 AM Houston Putman <[email protected]> >>>>>> 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 are mainly there just for >>>>>>> bureaucratic purposes. So I think it would be a wonderful direction to >>>>>>> go >>>>>>> in. >>>>>>> >>>>>>> >>>>>> On that note, many such projects I find it more difficult to get >>>>>> clarity on whether or not I'm affected by the issue, or in what version >>>>>> it >>>>>> was resolved. Usually i can be achieved by clicking on the referenced >>>>>> commit, and then inspecting what tags are on that commit, but it's >>>>>> several >>>>>> clicks and a minute or two vs just looking at the field in Jira... >>>>>> >>>>>> This can be made easier by using milestones as seen here (random >>>>>> example, used gradle because it's a very large, healthy project): >>>>>> https://github.com/gradle/gradle/issues/20182 >>>>>> >>>>>> But I've seen a lot of projects that don't do that... which probably >>>>>> colors my view a bit. >>>>>> >>>>>> -Gus >>>>>> >>>>>> -- >>>>>> http://www.needhamsoftware.com (work) >>>>>> http://www.the111shift.com (play) >>>>>> >>>>> >>>>> >>>>> -- >>>>> Marcus Eagan >>>>> >>>>> -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
