I'll give it a try though, I'm really skeptical that it can be done with a satisfactory level of quality (we want to "preserve" issue history, not just to have shallow/degraded copies, right?), and the migration will be significantly delayed to figure out the way to properly moving all issues to GitHub. if there is another way to bypass this challenge - please let me know.
Tomoko 2022年6月18日(土) 15:44 Dawid Weiss <[email protected]>: > > > Hi Tomoko, > > I've added a few bullet points that script could/should handle under > LUCENE-10557, hope you don't mind. If you place these script(s) in the open > then perhaps indeed we could try to collaborate and see what can be done. > > Dawid > > On Sat, Jun 18, 2022 at 5:33 AM Tomoko Uchida <[email protected]> > wrote: >> >> Replying to myself - Jira issues can be read via REST API without any >> access token and we can iterate all issues by issue number. >> curl -s https://issues.apache.org/jira/rest/api/latest/issue/LUCENE-10557 >> >> Would you please hold the discussion for a while - it's a waste of our >> time without a working prototype to me. I will be back here with a >> sandbox github repo where part of existing jira issues are migrated >> (with the best effort). >> In the process, we could simultaneously figure out the way to operate >> GitHub metadata (milestones/labels). >> >> Tomoko >> >> 2022年6月18日(土) 10:41 Tomoko Uchida <[email protected]>: >> >> > >> > Does anyone have information on API access keys to Jira (preferably, >> > read-only and limited to Lucene project)? >> > https://issues.apache.org/jira/browse/LUCENE-10622 >> > >> > 2022年6月18日(土) 10:11 Tomoko Uchida <[email protected]>: >> > > >> > > I feel like we should delay the decision on the mingration of existing >> > > issues until we have a clear image of what can be done and what cannot >> > > be done. >> > > >> > > I'll write some migration script that preserves the issue history as >> > > far as possible - then come back here with some experience. >> > > Let's make a decision upon the concrete knowledge and information. >> > > >> > > Tomoko >> > > >> > > 2022年6月18日(土) 9:26 Tomoko Uchida <[email protected]>: >> > > > >> > > > I don't intend to neglect histories in Jira... it's an important, >> > > > valuable asset for all of us and possible contributors in the future. >> > > > >> > > > It's important, *therefore*, I don't want to have the degraded copies >> > > > of them on GitHub. >> > > > We cannot preserve all of history - again, there should be tons of >> > > > unignorable information losses (timestamp, reporter, assignee, >> > > > markdown, metadata that cannot be ported to GitHub) if we attempt to >> > > > migrate the whole Jira history into Github. Rather than trying to have >> > > > such incomplete copies, I would preserve Jira issues in the perfectly >> > > > archived status, then simply refer to them. >> > > > >> > > > Tomoko >> > > > >> > > > 2022年6月18日(土) 7:47 Gus Heck <[email protected]>: >> > > > > >> > > > > I hope you count me as someone who sees history as important. It's >> > > > > important in more ways than one however. You gave the example of >> > > > > trying to understand something, and looking at the issue history >> > > > > directly. I also give weight to the scenario where someone has >> > > > > written a blog post about the topic and linked the issue "For the >> > > > > latest see LUCENE-XXXX" for example... Or someone planning upgrades >> > > > > has a spreadsheet of things to track down... The existing links >> > > > > should point to a *complete* history of the issue. >> > > > > >> > > > > I don't see the migration of everything to github as being as >> > > > > critical as you do but I'm not at all against migrating things that >> > > > > are closed if someone wants to do that work, and perhaps even >> > > > > copying over existing open issues periodically as they become closed >> > > > > (and accelerating the close rate by aggressive closing of silent >> > > > > issues). No new issues in Jira sounds fine, even better if enforced >> > > > > by Jira. Proceed from here in Github since that's where the >> > > > > community wants to go. Links to the migrated version automatically >> > > > > added to Jira and/or backlinks to Jira would be just fine too since >> > > > > readers might (hopefully needlessly) worry that something didn't get >> > > > > migrated, we should make it easy to check. >> > > > > >> > > > > What I don't want is for someone to land on an issue via link or via >> > > > > google search (or via search in jira because they are using Jira >> > > > > already for some other apache project), read through it and think A) >> > > > > it never got resolved when it did or B) miss the fact that it got >> > > > > reopened and further changes were made and only have half the >> > > > > story... or any other scenario where they are looking at an >> > > > > incomplete record of the issue. (thus obfuscating/splitting the very >> > > > > important rich history across systems). >> > > > > >> > > > > So that's why I feel issues should be completely tracked in the >> > > > > system where they were created. Syncing old closed stuff into a new >> > > > > system probably is fine so long as there are periodic sweeps to pull >> > > > > in reopens or newly completed issues. We could even sync open things >> > > > > so long as they are clearly marked in the title as having their >> > > > > primary record in Jira and "last synced from JIRA on YYYY-MM-DD" or >> > > > > something in a final comment each time new content is brought over. >> > > > > >> > > > > For simplicity and workload however maybe just sync things when they >> > > > > close. Depends on how much effort the person writing code for >> > > > > syncing things wants to put into it I guess. >> > > > > >> > > > > Although I agree with Dawid on the "What if Elon buys it?" issue, >> > > > > that ship has sailed, the community accepts that risk and we >> > > > > probably should not rehash it. >> > > > > >> > > > > WRT Robert's comments on PRs being issues... this has already >> > > > > worried me because I've already seen a lot of discussion on PR's and >> > > > > I've worried that this stuff has the potential to get lost or be >> > > > > hard to find. If there is one key positive of this move is that they >> > > > > will become easier to find since the search in github can find it. I >> > > > > would say that a PR is not a substitute for a well described issue >> > > > > report but that's probably a separate discussion (which I would hope >> > > > > mirrors the policy on small edits like typos or adding >> > > > > comments/javadoc not needing an issue). I've also seen folks who >> > > > > like to clean up and remove old branches and PR's, which is >> > > > > problematic if that's where the important discussion is (possibly a >> > > > > 3rd can of worms there). >> > > > > >> > > > > -Gus >> > > > > >> > > > > On Fri, Jun 17, 2022 at 4:34 PM Robert Muir <[email protected]> wrote: >> > > > >> >> > > > >> On Fri, Jun 17, 2022 at 3:27 PM Dawid Weiss <[email protected]> >> > > > >> wrote: >> > > > >> > >> > > > >> > I'd be more afraid of what happens to github issues in two years >> > > > >> > (or longer). Will it look the same? Will it be different? Will it >> > > > >> > be gone (and how do we get a backup of the isse history then)? >> > > > >> > Contrary to the apache-hosted Jira, github is very much an >> > > > >> > independent entity. If Elon Musk decides to buy and close it >> > > > >> > tomorrow... then what? :) >> > > > >> > >> > > > >> >> > > > >> We already have a ton of github "issues" (pull requests, since PRs >> > > > >> are issues). >> > > > >> If you want to "back them up", its easy, you can paginate thru them >> > > > >> 100 at a time, e.g. run this command, incrementing 'page' until it >> > > > >> returns empty list: >> > > > >> >> > > > >> curl -H "Accept: application/vnd.github.v3+json" >> > > > >> "https://api.github.com/repos/apache/lucene/issues?per_page=100&page=1&direction=asc&state=all"; >> > > > >> > file1.json >> > > > >> >> > > > >> Yeah of course if you want to backup the comments and stuff, you'll >> > > > >> need to do more. >> > > > >> But it is already the case today, that a ton of this "history" is >> > > > >> already in github issues, as PRs. Most recent JIRAs are just useless >> > > > >> placeholders. >> > > > >> Also the same risks apply to JIRA, except are not theoretical and >> > > > >> real >> > > > >> concerns, no? I thought Atlassian had deprecated "onsite" JIRA to >> > > > >> try >> > > > >> to sucker you into their "Atlassian Cloud": >> > > > >> https://www.theregister.com/2020/10/19/atlassian_server_licenses/ >> > > > >> >> > > > >> --------------------------------------------------------------------- >> > > > >> To unsubscribe, e-mail: [email protected] >> > > > >> For additional commands, e-mail: [email protected] >> > > > >> >> > > > > >> > > > > >> > > > > -- >> > > > > http://www.needhamsoftware.com (work) >> > > > > http://www.the111shift.com (play) >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
