Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-dev] Deprecating Bugzilla and Gerrrit?

Hi,

On Fri, Dec 18, 2020 at 12:45 AM Alex Blewitt <alex.blewitt@xxxxxxxxx> wrote:
A mail sent out by Denis suggests that Bugzilla and Gerrit are not long for this (eclipse) world, and that we will all be able to use GitHub or GitLab:

I've sent an answer to Denis, CC'd the committer representatives about some of my personal concerns with moving existing projects such as Platform away from Bugzilla, as I believe Bugzilla has enabled workflows (queries, dependency relationship...) that would be almost impossible to implement with the other suggested trackers. I'm afraid forcing a move to Bugzilla and losing such workflows would be extremely bad for the Eclipse project, but the concerns are voiced. Ideally, the EF can provide a very safe migration path of all data and of *all workflows*, and we just adapt a bit and everyone is happy; but I'm not convinced such a safe migration path exists at the moment and I'm not sure those can even be implemented without evolution on GitLab or GitHub.

I think this means we lose access to the last couple of decades of bug references

I don't know the details, but I somehow trust that EF will provide some proper ways to migrate all data, or at least to still reference it (ie keeping bugzilla read-only). EF has a decent track record of such migrations IMO, I'm not too worried about the data -although we definitely need to keep an eye on it-, I'm more worried about the workflows as mentioned above. GitLab and GitHub trackers are nice, but they seem semantically very weak compared to Bugzilla and the Eclipse project cannot really deal efficiently with such weak trackers efficiently.
 
and won’t be able to do per commit review and testing any more.

I think we can just learn new ways here. I love Gerrit, a lot, and I think it is the best review tool and I think that the hype around GitLab and GitHub is only about the "social" part and CSS but that their underlying model is not half as good as Gerrrit; but as I've used GitHub, I found that one can easily implement with GitHub similar workflows as the ones mandated by Gerrit; it's mostly a matter of asking contributors to put a single commit on their topic branch and to use `git commit --amend` and `git push --force`, or to squash commits to modify the branch. Then the Jenkinsfile integration will react properly to such updates, similarly to what Gerrit provides.
m2e, tm4e, Wild Web Developer and Corrosion use that approach, and the feedback (review, CI) approach is comparable to what's provided with Gerrit.

Back to the top