|Re: [eclipse.org-committers] build.eclipse.org will be going away - March 31, 2021|
Some great questions there, Ed.
First off, though, I'd like to clarify
that in the case of deprecating/removing Bugzilla, Gerrit and
MediaWiki, it is currently my thoughts about what I intend to propose,
not a strong-armed directive. Removing build.eclipse.org is not
proposed anymore, that one is happening. Now for some answers:
Will the migration from Bugzilla to GitLab be lossless in the same way that migration from CVS to GIT was pretty lossless?
Currently, bugs are imported, along with all comments and
attachments. A link back to the original bug is also included. The
biggest hurdle currently is that all issues and comments are
attributed to the import user (Webmaster) with the name of the
original author as part of the comment, which is far from ideal.
We intend to address this  Optionally, a comment can be added
to the bug with a link to the GitLab issue.
Further will there be a set of very long term legacy links from all the long and short form Bugzilla URIs so that anyone browsing e.g. https://wiki.eclipse.org/OCL/New_and_Noteworthy/Photon will find that the links work just as before, just linking to the GitLab Issue successor to the Bugzilla?
Yes, we will ensure that the current URLs for bugs work for a
very, very long time. I am unsure about links to attachments,
dependency trees and searches, however. Those will likely not work
In so far as the GitLab migration is actually, or suspected to be, less than 100% lossless will there be an automatic "see-also" in GitLab to direct back at the original Bugzilla perhaps hosted by https://oldbugs.eclipse.org?
As mentioned, we plan on preserving
https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXXX for a very
long time. Likely in a static HTML form. The imported bugs do
contain a link back to the original bug.
Thanks for the questions,
On 18/12/2020 17:17, Mickael Istria wrote:
On Fri, Dec 18, 2020 at 6:00 PM Denis Roy <denis.roy@xxxxxxxxxxxxxxxxxxxxxx> wrote:
Yes, GitLab supports issue dependency, even across repositories /
projects. See this as an example, where GitLab issue #1 is blocked by
Technology/Dash issue #146
Great, I stand corrected and see that as a major benefit of GitLab. That removes the main concern I got about such a migration away from Bugzilla!
Back to the top