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 <tomoko.uchida.1...@gmail.com>: > > 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 <gus.h...@gmail.com>: > > > > 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 <rcm...@gmail.com> wrote: > >> > >> On Fri, Jun 17, 2022 at 3:27 PM Dawid Weiss <dawid.we...@gmail.com> 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: dev-unsubscr...@lucene.apache.org > >> For additional commands, e-mail: dev-h...@lucene.apache.org > >> > > > > > > -- > > http://www.needhamsoftware.com (work) > > http://www.the111shift.com (play) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
