Totally agree. The history of closed issues answer “when did this change and 
why?”. Migrate them all. Computers can do that. It avoids asking humans to 
think about where stuff is.

wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)

> On Jun 15, 2022, at 6:49 AM, Michael McCandless <luc...@mikemccandless.com> 
> wrote:
> 
> 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 <http://blog.mikemccandless.com/>
> 
> On Wed, Jun 15, 2022 at 9:34 AM Michael Sokolov <msoko...@gmail.com 
> <mailto: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 
> <mailto: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 
> > <mailto: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 
> <mailto:dev-unsubscr...@lucene.apache.org>
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> <mailto:dev-h...@lucene.apache.org>
> 

Reply via email to