Re: [m2e-dev] Moving Git repo to GitHub?

[Matthew Piggott <mpiggott@xxxxxxxxxxxx>]

Github can be configured to automatically link to external issue trackers -https://help.github.com/en/github/administering-a-repository/configuring-autolinks-to-reference-external-resources

On Fri, 5 Jun 2020 at 03:54, Aleksandar Kurtakov <akurtako@xxxxxxxxxx> wrote:

On Fri, Jun 5, 2020 at 10:39 AM Mickael Istria <mistria@xxxxxxxxxx> wrote:

On Fri, Jun 5, 2020 at 9:22 AM Christoph Läubrich <laeubi@xxxxxxxxxxxxxx> wrote:

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.

^ +1

 

- 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.

If it's possible a working solution would be keeping bugzilla open but blocking new bugs against m2e so new bugs go to github while old bugs are around and can be commented/closed/etc. until queue is cleared. Of course this might not be technically possible and it should be potential step 2 not blocking actual move of git repos.

 

- 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 ;)

_______________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/m2e-dev

--

Alexander Kurtakov

Red Hat Eclipse Team

_______________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/m2e-dev