Are either mxr or dxr really the right thing for canonical links to our
source code? As long as we're updating links, through one means or
another, temporarily or permanently, couldn't we come up with a set of
urls that would be better in the long term? One that clearly states the
purpose of a link (eg a link to the latest version of a whole file vs a
link to a range of lines in a specific version vs a link to a named
function definition or whatever), and could be redirected when the next
great thing comes along?
I think of dxr as a code searching site, not an archival one.
hg.mozilla.org would seem to be better for versioned links, although I
would optimize for different performance characteristics and feature
sets than if I were setting up an archival service, so in my opinion
it's not the best choice either.
I'm not saying we should block everything on some hypothetical new
archival server, just that an additional layer of indirection might be
well-placed here. The archival urls can do some simple forwarding for
now. (And it would be nice for dxr/searchfox to offer up archival links
with these urls.) It'd even be fine if the archival versions pointed
back into dxr and/or hg.m.o or whatever.
Just a thought.
On 07/08/2016 12:27 PM, Lawrence Mandel wrote:
We do in the case of 3rd party software referencing files from MXR (and I'm
told there is a lot of this). We also can't guarantee that MXR URLs will
direct to the right place in DXR. There is likely a balance to be struck
here with highly referenced files from 3rd party software getting an
interstitial page and other files not getting the page. Let's start with
getting the page with the redirect in place and then iterate from there as
required.
Lawrence
On Fri, Jul 8, 2016 at 3:24 PM, Bobby Holley <bobbyhol...@gmail.com> wrote:
Can we skip the interstitial page and make the notice (if any) more
unobtrusive somehow? There are tons of mxr links all over the place, and
many of them are immutable. We don't gain anything by informing the viewer
about their obsolescence instead of showing them the content they want.
On Fri, Jul 8, 2016 at 12:20 PM, Lawrence Mandel <lman...@mozilla.com>
wrote:
dev-platform was not included on my response below. Looping back in to
this
fork of the thread.
On Fri, Jul 8, 2016 at 10:55 AM, Lawrence Mandel <lman...@mozilla.com>
wrote:
Sorry Dao. I have seen some responses. Maybe they were off list. We're
working on details now. I'm going to get someone to put the redirects in
place, likely with an interstitial page advising that MXR has been
decommissioned, by next week.
Lawrence
On Friday, 8 July 2016, Dão Gottwald <dgottw...@mozilla.com> wrote:
Why has nobody responded to the requests for a short-term fix for MXR
URLs for more than a week? Are the people responsible for MXR not in
this
list?
2016-07-07 18:23 GMT+02:00 Eric Shepherd <esheph...@mozilla.com>:
We have tons of mxr links all through MDN, fwiw. I am updating the
macros that generate them, but odds are very good these links will be
around for a good while.
That would be perfectly fine for my purposes, I expect, as long as it
dealt with the relevant mxr features. What I want is for links to
possibly
specific lines of possibly specific revisions of specific files to
work.
Ideally with the highlighting bits too.
--
Eric Shepherd
Senior Technical Writer
Mozilla Developer Network <https://developer.mozilla.org/>
Blog: https://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Doodle: http://doodle.com/the.sheppy
_______________________________________________
firefox-dev mailing list
firefox-...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
