Thank you Mike for your support and comment. > 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.
I'm just curious - all Jira issues always will be there and accessible from anywhere (at least in a readable state), and we can reach them from our CHANGES anytime. They won't be lost, and of course, we can link to Jira issues from GitHub issues for tracking their history/background. So - what is the point of "preserve our detailed Jira issue history on migration" in GitHub? I understand the code and commit history are our most important assets, and the effort to preserve them in a whole, linear history perfectly makes sense to me. On the other hand, issues are in slightly different context from commit history, I think. Personally, I don't believe automate migration tools between proprietary services - I'm almost sure there will be some information losses if we attempt to migrate the whole Jira issue into Github... Rather than trying to do that, I would prefer to let Jira issues as is, then simply refer them. (I'm not so knowledgeable, so correct me if there are perfectly reliable tools for Jira -> GitHub migration.) If we need a federated search for both Jira and GitHub, I think we already have a great one - https://jirasearch.mikemccandless.com/search.py Tomoko 2022年5月12日(木) 0:09 Michael McCandless <luc...@mikemccandless.com>: > The top reason for me to support moving our project to GitHub is to lower > friction for the growth of the Lucene developer community. > > I myself am far less comfortable with GitHub issues than Jira, but that's > really unimportant. I can and will figure it out (like highlighting text > and hitting "r", yay!). I would hope/expect the same for all "old-timers" > here :) > > Our community grows only at its periphery, with younger, passionate > people (who generally have strong comfort in GitHub and not with Jira). > > Anything and everything we can do to reduce the friction for such Fresh > Eyes / Shoshin / 初心 users, we must do. The long-term survival of our > (currently still vibrant, but that can change) community relies on > continued growth by doing everything possible to encourage new users, > growing to contributors, to committers, to PMC members, to Apache members. > I put this in the same bucket as "try to promptly respond to new people who > send emails to our lists" and "aggressively try to fix the silly issues a > new contributor hits" (like the recent "gradlew tidy" improvements from > Rich Bowen's "the the" first Lucene contribution). > > Fresh Eyes is a sharp tool that quickly dulls, and we old-timers can no > longer sense nor appreciate/empathize-with the problems new contributors > hit, to our ("whole Lucene dev community") detriment. > > Also, I really do not like that Jira silently blocks your IP if you try to > add a link to an external PDF that has the word "dissertation" in it! This > leads to confusion (especially if you are coming through a VPN since that > VPN's endpoint is blocked so anyone else sharing that endpoint, later, will > also see the silently dropped packets (spinning browser) when trying to add > comments to Jira). This is just a pet peeve LOL. Also, Apache's slow > adoption/enabling of modern Jira features like supporting Markdown does not > help the Jira case, also a pet peeve! > > 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. > > 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. > > Mike McCandless > > http://blog.mikemccandless.com > > > On Wed, May 11, 2022 at 12:58 AM Tomoko Uchida < > tomoko.uchida.1...@gmail.com> 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 <juliet...@gmail.com>: >> >>> 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 <hous...@apache.org> >>> 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 <marcusea...@gmail.com> >>>> 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 <gus.h...@gmail.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Tue, May 10, 2022 at 10:40 AM Houston Putman <hous...@apache.org> >>>>>> 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 >>>>> >>>>>
