| Re: [eclipse.org-committers] build.eclipse.org will be going away - March 31, 2021 |
Hi
It is a parametric redirect so potentially some script can access
a secondary mapping database rather than a primary URI mapping,
but in order to make the traditional reference redirect to the
new, what is the alternative? Maybe the new GitLab 'ID's can be
something like bugzillaXXXXXX so that the mapping trivial.
If the old URI is not redirected how do users continue commenting on the replacement GitLab issue?
Regards
Ed Willink
On Mon., Dec. 21, 2020, 13:03 Ed Willink, <ed.willink@xxxxxxxxx> wrote:
Hi Denis
That substantially puts my mind at rest. However I'm puzzled by:
On 21/12/2020 15:02, Denis Roy wrote:
>
> 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.
>
Surely https://bugs.eclipse.org/bugs/show_bug.cgi?id=XXXXXX must
redirect to the successor GitLab issue, so a new e.g.
https://oldbugs.eclipse.org/bugs/show_bug.cgi?id=XXXXXX is needed when
accessing the original?
I assume that would require lots of different redirects based on bug number which I assume is infeasible. So the comment at the end of the bug, or in some other place makes sense?
Also, i am considering not moving bugs at all for at least some projects. The move of infra provides an opportunity (for some projects that want it) to have a clean break.
Jonah
Regards
Ed Willink
--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
eclipse.org-committers mailing list
eclipse.org-committers@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-committers