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.
> 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). Tomoko 2022年6月15日(水) 22:51 Michael McCandless <luc...@mikemccandless.com>: > > I would prefer that we migrate all issues to GitHub and then make the Jira > project read only. > > There is a rich history to our project in these issues that we should not > discard. This is a unique property of Apache Lucene since our project has > been in existence and so vibrant for so much time. Those who do not > know/study history are doomed to repeat it :) > > Expecting new developers to remember to "oh, long ago this project used this > old thing called Jira, you have to go search that, to find out why XYZ was > done this way in Lucene, pre-Github-issue-migration" is not a good solution > -- many won't remember (nor eventually, know) to do so. > > If I saw it correctly, at least two other projects (or maybe two people from > the same project, not sure) created a one-off tool to perform the migration > for their projects. It isn't perfect of course (GitHub issues may not be > able to represent all metadata that Jira has), but we should migrate what is > possible. > > Mike McCandless > > http://blog.mikemccandless.com > > > On Wed, Jun 15, 2022 at 9:34 AM Michael Sokolov <msoko...@gmail.com> wrote: >> >> Agree with everyone here. Also consider that if we duplicate there >> will be two copies of the same issue, and they will inevitably >> diverge... >> >> On Wed, Jun 15, 2022 at 9:28 AM Jan Høydahl <jan....@cominvent.com> wrote: >> > >> > +1 for a manual approach >> > >> > Over time the volume will gravitate to mostly GitHub issues. And JIRA will >> > always remain as an archive, so nothing is lost. Devs can always peek into >> > the list of open JIRAs any time and choose to start a PR for one. A slight >> > disadvantage is of course that in the first year or two you need to look >> > in both systems to get a full overview of all open issues. But auto >> > migrating hundreds of abandoned JIRA issues to GitHub is no better imo. >> > >> > Jan >> > >> > 15. jun. 2022 kl. 13:03 skrev Dawid Weiss <dawid.we...@gmail.com>: >> > >> > >> >> Maybe a 3rd option could be to only use GitHub for new issues by adding >> >> some text to the Jira create issue dialog that says something like "JIRA >> >> is deprecated, please use GitHub for new issues" to encourage users to >> >> create new issues on GitHub instead of JIRA. >> > >> > >> > I was thinking this too, actually. It'd allow for a more graceful >> > transition period from one system to another. It'd also help keep >> > cross-links (from comments, etc.) in the old issues reference proper >> > targets. And I don't see many disadvantages - I imagine that folks who >> > wish to revisit old(er) open Jira issues and prefer GH can close the jira >> > ticket as a duplicate and open a new corresponding GH issue. Wouldn't this >> > be easier (for you as well)? The key change would be procedural -- allow >> > pull requests and github issues as first-class "change" tickets. >> > >> > D. >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
