I agree with the idea that we shouldn't have 2 active trackers, but I think that the apache jira must remain readable forever. People will have bookmarked or linked issues in documents, blog posts or web pages and breaking those links would be a HUGE disservice to the community. Ideally we would set Jira to not accept new issues and lock out comments on closed issues. New issues would then appear in github. If we were able to migrate a locked, read only copy of closed jira's into github (and include a link back to the original) that might be of some help to users so they can work in github and ignore Jira, but we should not allow further discussion in github of something discussed in Jira. Really bad to have someone look at an issue, think they have the full picture and be missing 1/3 of the discussion.
So principles I'd like to advocate are: 1) Don't break links to Jiras 2) Single source of truth for any individual issue. 3) Optionally for user convenience reflect the source of truth for old issues in github as read only, with a back reference. On Wed, Jun 15, 2022 at 11:56 AM Michael McCandless < luc...@mikemccandless.com> wrote: > On Wed, Jun 15, 2022 at 10:46 AM Tomoko Uchida < > tomoko.uchida.1...@gmail.com> wrote: > >> Thank you everyone for your suggestions. >> I don't have a strong opinion on how to handle existing issues, I just >> want to proceed with the migration smoothly. I'd open this discussion >> until we find a better (not perfect) option or reach some level of >> agreement. >> > > I see you already have a start at the migration plan, yay! (The comment > on LUCENE-10557) > > Could we maybe pull that out into a wiki page so we can more easily > collaborate on the steps? > > >> > make the Jira project read only. >> >> I'm sorry but I don't think we can make Jira read only... I think we >> should support the backup contribution paths outside GitHub, and >> personally, I don't want to back to a mail-based way. >> We've seen there are people who don't use GitHub for whatever reason >> and I think we can't ignore the risk of GitHub account banning - it >> can happen accidentally to anyone (I don't know the surveillance >> system in GitHub at all but it might be automated? Systems can make >> mistakes and recovering an account may take some time). >> > > Hmm, I think it's quite risky/dangerous to leave both writable? It'd be > forking our issue tracker. We'll have situations where some of us update > the Jira issue, others update the GitHub issue, we lose context/comments, > we duplicate work (thinking nobody is working on the GitHub issue yet > someone was actually working on the Jira one). It would add > risk/friction/taxation to development going forward ... people would need > to know to check two places (GitHub and Jira) for updates, new issues, > patches, linked PRs, etc. > > To me the migration would ideally be an atomic switch -- only Jira is > writeable up until some point, then it goes read only, we kick off the > (hopefully already well tested/debugged migration tool, probably just > forking this nice tool that the Lucene.net devs created > <https://github.com/bongohrtech/jira-issues-importer/tree/lucenenet>), > then GitHub issues is writable. > > This nicely matches how SVN -> Git migration went. > > Yes, some people are not fully comfortable with GitHub, yet, but we expect > that to be the minority, we expect account blocking to be rare and easy to > resolve, etc. (since our VOTE to migrate has passed). > > I really feel we should make a hard switch for the best long-term health > of the dev community. > > Mike McCandless > > http://blog.mikemccandless.com > -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
