GitHub issues is IMO a valuable tool to track changes/prs in git, for
example you can autoclose isses after they are merged to the master
FWIW, I personally perceive that as a bad feature as a partial patch or some patches that require some verification after merge automatically close an issue that still requires attention.
This is the kind of thing that makes GitHub actually scale not so well for non-trivial projects with non-trivial issue lifecycle IMO.
Would't it be possible to put the bugzilla into read-only mode or
something? With some scripting magic it would even be possible to create
issues in github that links to the original bugzilla ones.
Let's not make the issue tracking part of the migration at the moment and re-consider it later. Just moving the repo and pending patches is enough brainstorming matter and work at the moment.
if we are not in hurry for this change
I think we actually are in a hurry: it looks like everyone is OK to do it, there is currently good interest in m2e from external contributors, and we'll have some cycles to spend on it at the end of this month. Planets are aligned and this will not last forever, so let's just do it ASAP rather than leaving such important community development pending on a next planet alignment.
- active Gerrit Reviews
There are only a few of them. Dealing with them manually could be easier than trying to automate anything (
https://xkcd.com/1205/ ). I also assume that Gerrit patches remain accessible after the migration, just the Git repo becomes read-only.
- open issues
There are way too many of them, with important linkage to other issues inside m2e, or in JDT or in Platform as "depends" or "see also" (advanced linking and presenting a clear dependency model for issues is also something GitHub also sucks at and where Bugzilla is clearly better).
I believe it's too early to consider moving the issues, and as mentioned earlier, it will be more efficient to just disable GitHub issue tracker in the 1st step of the migration until we have a good migration plan for all Bugzilla issues.
My gut feeling is that we can technically not properly inject Bugzilla data into GitHub issues at all (mathematically, Bugzilla has more "dimensions" than what GitHub issues offers, making injection generally not possible), so we'll basically never be able to build a plan that's not destructive.
- jenkins triggers for building Reviews
CI instances can already build PRs and report a vote on the issue. It's been extensively used by many Eclipse.org project for a long time already, nothing to worry here.
So overall, everything seems relatively easy and safe to move, except bugs. So let's do everything, except bugs ;)
