Bugzilla

(In reply to Sylvestre Ledru [:Sylvestre] from comment #0)
> it isn't going to change much but the hgweb is taking heavy load. So, let's point to github instead of hgweb for log & raw.
> thanks

Because of the invaluable extra info hg.mozilla.org adds to revisions about the push and the https://buildhub.moz.tools/ -esque info about first release with/last release without as well as the mercurial "follow these lines through time" powers, I don't think we can remove the hgweb "Log" link affordance, but it definitely makes sense to use github for "Raw" and provide the github history link (like `https://github.com/mozilla/gecko-dev/commits/${gitrev}/${path}` as the favored "Log".  Then we could expose the existing hg log as "HG Log" after "Log" or maybe in its own (sub)section, depending on how people feel about the change to muscle memory for that and whether we can find a way to add easily add buildhub links[1] (which would also go in the new section).

Nicolas, can you take a look at this?  I believe from my notes in https://bugzilla.mozilla.org/show_bug.cgi?id=1890435#c0 that our revs are already hash compatible with gecko-dev.  This could also be a good opportunity to make sure we do github links for the other relevant repos like requested for wubkat in bug 1847297 and address the issue link logic for LLVM in bug 1874757.  Note that in bug 1847297 I proposed not including both hg and git links, but obviously this bug changes the rationale around that.  The [mozsearch index rust analysis search on the hg_root symbol works quite nicely](https://searchfox.org/mozsearch/search?q=symbol:S_rs_rust_config%2Ffile_format%2FTreeConfigPaths%23hg_root.&redirect=false) (and [the diagram is nice too, of course!](https://searchfox.org/mozsearch/query/default?q=calls-to%3A%27config%3A%3Afile_format%3A%3ATreeConfigPaths%3A%3Ahg_root%27%20depth%3A4)).

1: Like, we can make URLs like https://buildhub.moz.tools/?q=source.revision%3A250be4ca3c669db9a397456402f68249aa15d8d5 but the revision needs to be something that taskcluster built (for m-c?) AFAICT from https://buildhub2.readthedocs.io/en/latest/project.html#overview but I don't know that searchfox can effectively know that without ingesting additional data.  (And we would eventually want to ingest all that, but it's probably out of scope for now.)

(In reply to Sylvestre Ledru [:Sylvestre] from comment #0)
> it isn't going to change much but the hgweb is taking heavy load. So, let's point to github instead of hgweb for log & raw.
> thanks

Because of the invaluable extra info hg.mozilla.org adds to revisions about the push and the https://buildhub.moz.tools/ -esque info about first release with/last release without as well as the mercurial "follow these lines through time" powers, I don't think we can remove the hgweb "Log" link affordance, but it definitely makes sense to use github for "Raw" and provide the github history link (like `https://github.com/mozilla/gecko-dev/commits/${gitrev}/${path}` as the favored "Log".  Then we could expose the existing hg log as "HG Log" after "Log" or maybe in its own (sub)section, depending on how people feel about the change to muscle memory for that and whether we can find a way to easily add buildhub links[1] (which would also go in the new section).

Nicolas, can you take a look at this?  I believe from my notes in https://bugzilla.mozilla.org/show_bug.cgi?id=1890435#c0 that our revs are already hash compatible with gecko-dev.  This could also be a good opportunity to make sure we do github links for the other relevant repos like requested for wubkat in bug 1847297 and address the issue link logic for LLVM in bug 1874757.  Note that in bug 1847297 I proposed not including both hg and git links, but obviously this bug changes the rationale around that.  The [mozsearch index rust analysis search on the hg_root symbol works quite nicely](https://searchfox.org/mozsearch/search?q=symbol:S_rs_rust_config%2Ffile_format%2FTreeConfigPaths%23hg_root.&redirect=false) (and [the diagram is nice too, of course!](https://searchfox.org/mozsearch/query/default?q=calls-to%3A%27config%3A%3Afile_format%3A%3ATreeConfigPaths%3A%3Ahg_root%27%20depth%3A4)).

1: Like, we can make URLs like https://buildhub.moz.tools/?q=source.revision%3A250be4ca3c669db9a397456402f68249aa15d8d5 but the revision needs to be something that taskcluster built (for m-c?) AFAICT from https://buildhub2.readthedocs.io/en/latest/project.html#overview but I don't know that searchfox can effectively know that without ingesting additional data.  (And we would eventually want to ingest all that, but it's probably out of scope for now.)