Re: MXR permanently offline, please transition to DXR

[Boris Zbarsky]

On 7/8/16 11:37 PM, Eric Rahm wrote:

While mxr being retired is unfortunate, at this point would it not make
more sense to just file bugs against dxr for features you would like to
be added?


1) We're talking about hg.mozilla.org, not dxr.  There are existing bug 
reports on adding line highlighting to hgweb, I believe; they've been 
around for a while now.


2) When I last suggested (back when dxr usage was much lower than now) 
that dxr should stop using the fragment identifier for the set of lines 
to highlight, so you could combine highlighting with selection of a line 
to scroll to, I was flat out told that wasn't going to happen because 
dxr wanted to use the fragment identifier for highlighting.  Of course 
at this point changing the behavior would also break existing dxr links, 
even if there has been a change of heart...



It's not clear to me after this lengthy discussion if anything
actionable has been accomplished.


You're right, nothing has.

-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: MXR permanently offline, please transition to DXR

[Eric Rahm]

While mxr being retired is unfortunate, at this point would it not make
more sense to just file bugs against dxr for features you would like to be
added?

It's not clear to me after this lengthy discussion if anything actionable
has been accomplished.

-e

On Fri, Jul 8, 2016 at 7:57 PM, Boris Zbarsky  wrote:

> On 7/8/16 7:25 PM, Gerald Squelart wrote:
>
>> The annotate (aka blame) functionality of hg.mozilla.org can point at
>> one line
>>
>
> Yes, I know.  What it can't do is highlight some set of lines containing
> more than one line.  Think things like:
>
>   http://mxr.mozilla.org/whatever-file?mark=10-20,17,25#8
>
> which highlights lines 10-20, 17, and 25, and scrolls to line 8.  This is
> very useful when pointing people at code.
>
> -Boris
>
> ___
> 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

Re: MXR permanently offline, please transition to DXR

[Boris Zbarsky]

On 7/8/16 7:25 PM, Gerald Squelart wrote:

The annotate (aka blame) functionality of hg.mozilla.org can point at one line


Yes, I know.  What it can't do is highlight some set of lines containing 
more than one line.  Think things like:


  http://mxr.mozilla.org/whatever-file?mark=10-20,17,25#8

which highlights lines 10-20, 17, and 25, and scrolls to line 8.  This 
is very useful when pointing people at code.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: MXR permanently offline, please transition to DXR

[Gerald Squelart]

On Saturday, July 9, 2016 at 7:21:24 AM UTC+10, Boris Zbarsky wrote:
> On 7/8/16 4:18 PM, Steve Fink wrote:
> > 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?
> 
> Yes, please!
> 
> Especially because DXR doesn't allow independent specification of "lines 
> to highlight" and "line to scroll to", so any conversion from mxr links 
> to dxr ones will be somewhat lossy...
> 
> There's still the question of what to back the links with of course 
> (that is, what runs on the server).
> 
> > hg.mozilla.org would seem to be better for versioned links
> 
> Can't highlight lines there, last I checked.
> 
> -Boris

The annotate (aka blame) functionality of hg.mozilla.org can point at one line, 
e.g.:
https://hg.mozilla.org/mozilla-central/annotate/c2da34d96746288b5fee27bf6542a12c9f410988/dom/media/platforms/PDMFactory.cpp#l126
(Hash, lowercase 'L', line number)
I've opened https://bugzil.la/1282329 requesting that DXR generates these as 
recommended permalinks -- Hope you like it. :-)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: MXR permanently offline, please transition to DXR

[Tanvi Vyas]

On 7/8/16 12:49 PM, Gijs Kruitbosch wrote:
In case this is useful for folks: I wrote a webextension that rewrites 
these links and that obeys the "rev" and "mark" query params from MXR 
links and rewrites them to the equivalent DXR URL syntax: 
https://addons.mozilla.org/en-US/firefox/addon/mxr-to-dxr-webextension/ .


~ Gijs


Thank you Gijs!



On 08/07/2016 20:27, 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  
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
 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
>
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 > 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
>:
>>
>>> 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 
>>> 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





___
firefox-dev mailing list
firefox-...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev





___
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

Re: MXR permanently offline, please transition to DXR

[Boris Zbarsky]

On 7/8/16 4:18 PM, Steve Fink wrote:

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?


Yes, please!

Especially because DXR doesn't allow independent specification of "lines 
to highlight" and "line to scroll to", so any conversion from mxr links 
to dxr ones will be somewhat lossy...


There's still the question of what to back the links with of course 
(that is, what runs on the server).



hg.mozilla.org would seem to be better for versioned links


Can't highlight lines there, last I checked.

-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: MXR permanently offline, please transition to DXR

[Lawrence Mandel]

I filed bug 1285657 to rewrite MXR links in Bugzilla to DXR. Are there
other sites (MDN) that have a lot of links that we should look to rewrite?

Lawrence

On Fri, Jul 8, 2016 at 3:49 PM, Gijs Kruitbosch 
wrote:

> The problem is that if you're on a bmo page with these "perma"links,
> really the ideal case is that they are indeed permalinks and continue to
> work, especially where they point to specific lines in specific revisions.
> The interstitial just makes it harder for people to get to that info. A 404
> on a working DXR, if the file has really disappeared or something, is still
> better than the 'hard hat' page from which the path to the data you want is
> much longer.
>
> In case this is useful for folks: I wrote a webextension that rewrites
> these links and that obeys the "rev" and "mark" query params from MXR links
> and rewrites them to the equivalent DXR URL syntax:
> https://addons.mozilla.org/en-US/firefox/addon/mxr-to-dxr-webextension/ .
>
> ~ Gijs
>
>
> On 08/07/2016 20:27, 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 
>>> 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  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 :
>>> >>
>>> >>> 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
>>>
>>
>>
>
>
> ___
> firefox-dev mailing 
> listfirefox-dev@mozilla.orghttps://mail.mozilla.org/listinfo/firefox-dev
>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: MXR permanently offline, please transition to DXR

[Boris Zbarsky]

On 7/8/16 3:23 PM, Lawrence Mandel wrote:

On Fri, Jul 8, 2016 at 11:10 AM, Boris Zbarsky > wrote:
Why do we need the interstitial page for direct links to files?
What action is expected to be taken by the person who followed that
link, other than having to do extra clicks?

Few things:
- Want to encourage people to update their links to DXR.


This won't help with existing links from Bugzilla, obviously.


- Lots of 3rd party software is directly linking to files in MXR. We
want to provide a path to fixing these links now that MXR is offline.


OK.  Sounds like you may want to skip the interstitial based on referrer 
or something.  Because having this interstitial for bugzilla links just 
sounds like a PITA.



- Not all links will work.


Which ones won't?  Why won't they work?

-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: MXR permanently offline, please transition to DXR

[Steve Fink]

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  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 
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 
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  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 :


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 
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

Re: MXR permanently offline, please transition to DXR

[Gijs Kruitbosch]

The problem is that if you're on a bmo page with these "perma"links, 
really the ideal case is that they are indeed permalinks and continue to 
work, especially where they point to specific lines in specific 
revisions. The interstitial just makes it harder for people to get to 
that info. A 404 on a working DXR, if the file has really disappeared or 
something, is still better than the 'hard hat' page from which the path 
to the data you want is much longer.


In case this is useful for folks: I wrote a webextension that rewrites 
these links and that obeys the "rev" and "mark" query params from MXR 
links and rewrites them to the equivalent DXR URL syntax: 
https://addons.mozilla.org/en-US/firefox/addon/mxr-to-dxr-webextension/ .


~ Gijs

On 08/07/2016 20:27, 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 > 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
> 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
>
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 > 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
>:
>>
>>> 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 
>>> 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





___
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

Re: MXR permanently offline, please transition to DXR

[Lawrence Mandel]

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  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 
> 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 
>> 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  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 :
>> >>
>> >>> 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 
>> >>> 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

Re: MXR permanently offline, please transition to DXR

[Bobby Holley]

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 
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 
> 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  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 :
> >>
> >>> 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 
> >>> 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

Re: MXR permanently offline, please transition to DXR

[Lawrence Mandel]

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 
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  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 :
>>
>>> 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 
>>> 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

Re: Checkin-needed requests - Please include complete information in the commit message :)

[Gregory Szorc]

On Fri, Jul 8, 2016 at 11:39 AM, Felipe G  wrote:

> Is there a way to make the checkin-needed flag generate a template comment
> (like the approval-* ones do) with something like this? (Or encourage
> people to use the per-patch checkin? flag)
>
> """
> Has this patch been through try? [ Yes / No, I believe it's not necessary ]
> Does this patch contain the correct author / commit message? [ Yes
> (preferred) / No, but I'm providing it here: ]
> Are there any other dependencies that should be landed together? [ Yes, ...
> / No ]
> """
>
> Probably just asking if the information is present will reduce the number
> of requests made without it
>

My knee jerk reaction is we shouldn't bother: MozReview handles most of
this "validation" and usage of MozReview has been steadily increasing.
We're trending towards a world where the only patches on Splinter are for
security-sensitive bugs (MozReview can't handle those yet) and the people
submitting patches to security bugs tend to know what they're doing so I
don't think these added checks will help.


>
> On Fri, Jul 8, 2016 at 10:47 AM, Ryan VanderMeulen 
> wrote:
>
> > FWIW, there's also an MDN page that documents a lot of this as well:
> >
> >
> https://developer.mozilla.org/en-US/docs/Mercurial/Using_Mercurial#How_can_I_generate_a_patch_for_somebody_else_to_check-in_for_me.3F
> >
> > -Ryan
> >
> >
> > On 7/8/2016 2:32 AM, Carsten Book wrote:
> >
> >> Hi,
> >>
> >> someone might not know that doing checkins for checkin-needed request is
> >> not automated yet and completely a fully human task :) (no we Sheriffs
> are
> >> not bots ;)
> >>
> >> It would help us a lot if a checkin needed request would contain
> complete
> >> Author/Patch information like:
> >>
> >>
> >>- Author (use the information from their Bugzilla account if needed)
> >>with Name *and *Emailadress.
> >>- Bug number
> >>- Commit message (keeping in mind that the commit message should be a
> >>brief description of what the patch is *doing*)
> >>   - Format should be something like "Bug 123456 - Add a null check
> to
> >>   XYZ to avoid a crash. r=somebody"
> >>
> >>
> >> And also if there is a specific sequence/dependency you want to checkin
> >> the
> >> patches it would help also a lot  if you could make a short comment in
> the
> >> Bug like please checkin part x then patch y or like first bug 123 then
> >> this
> >> bug and then bug 8910.
> >>
> >> This would help us a lot :)
> >>
> >> Thanks!
> >>
> >> - Tomcat
> >>
> >>
> > ___
> > 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

Re: Checkin-needed requests - Please include complete information in the commit message :)

[Felipe G]

Is there a way to make the checkin-needed flag generate a template comment
(like the approval-* ones do) with something like this? (Or encourage
people to use the per-patch checkin? flag)

"""
Has this patch been through try? [ Yes / No, I believe it's not necessary ]
Does this patch contain the correct author / commit message? [ Yes
(preferred) / No, but I'm providing it here: ]
Are there any other dependencies that should be landed together? [ Yes, ...
/ No ]
"""

Probably just asking if the information is present will reduce the number
of requests made without it

On Fri, Jul 8, 2016 at 10:47 AM, Ryan VanderMeulen  wrote:

> FWIW, there's also an MDN page that documents a lot of this as well:
>
> https://developer.mozilla.org/en-US/docs/Mercurial/Using_Mercurial#How_can_I_generate_a_patch_for_somebody_else_to_check-in_for_me.3F
>
> -Ryan
>
>
> On 7/8/2016 2:32 AM, Carsten Book wrote:
>
>> Hi,
>>
>> someone might not know that doing checkins for checkin-needed request is
>> not automated yet and completely a fully human task :) (no we Sheriffs are
>> not bots ;)
>>
>> It would help us a lot if a checkin needed request would contain complete
>> Author/Patch information like:
>>
>>
>>- Author (use the information from their Bugzilla account if needed)
>>with Name *and *Emailadress.
>>- Bug number
>>- Commit message (keeping in mind that the commit message should be a
>>brief description of what the patch is *doing*)
>>   - Format should be something like "Bug 123456 - Add a null check to
>>   XYZ to avoid a crash. r=somebody"
>>
>>
>> And also if there is a specific sequence/dependency you want to checkin
>> the
>> patches it would help also a lot  if you could make a short comment in the
>> Bug like please checkin part x then patch y or like first bug 123 then
>> this
>> bug and then bug 8910.
>>
>> This would help us a lot :)
>>
>> Thanks!
>>
>> - Tomcat
>>
>>
> ___
> 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

Re: Why do we still need to include Qt widget in mozilla-central?

[Benjamin Smedberg]

This is now done, as of https://bugzilla.mozilla.org/show_bug.cgi?id=1282866
the Qt code has been removed from mozilla-central.

--BDS

On Fri, Jun 24, 2016 at 11:57 AM, Douglas Turner  wrote:

> I am a peer.  Feel free to file a bug against me to remove this port. It
> served it's purpose. Anyone that wants to keep it alive can do it outside
> of m-c (long live dvcs).
>
>
>
> On Thu, Jun 23, 2016 at 12:35 PM Benjamin Smedberg 
> wrote:
>
>> I'm going to resurrect this old thread to ask: is anybody currently
>> triaging bugs the Core: Widget: Qt bugzilla component? I'm trying to find
>> owners for all of our active bugzilla components, and I'm not sure the
>> status of this.
>>
>> I would support us removing the widget/qt code from the tree unless we
>> have
>> clear ownership not only of reviewing patches, but the supporting
>> activities such as bug triage and some kind of continuous automation.
>>
>> --BDS
>>
>> On Sun, Apr 17, 2016 at 11:12 AM, Raine Mäkeläinen <
>> raine.makelai...@gmail.com> wrote:
>>
>> > I think that in this context we are talking about mozilla/widget/qt/*
>> > components and yes we're using those in our Gecko build. We don't use
>> > QWidgets for Sailfish Browser. User interface of the Sailfish Browser is
>> > written with Qt QML.
>> >
>> > There is more info in the embedding wiki [1] and Dmitry's blog [2].
>> > Rendering pipeline has changed after Dmitry's blog post but otherwise
>> quite
>> > close to the current state.
>> >
>> > [1]
>> > https://wiki.mozilla.org/Embedding/IPCLiteAPI
>> >
>> > [2]
>> > http://blog.idempotent.info/posts/whats-behind-sailfish-browser.html
>> >
>> > -Raine
>> >
>> > 2016-04-14 20:38 GMT+03:00 Henri Sivonen :
>> >
>> > > Added Raine Mäkeläinen, who has been committing to qtmozembed lately,
>> to
>> > > CC.
>> > >
>> > > On Thu, Apr 14, 2016 at 1:51 AM, Jim Blandy 
>> wrote:
>> > > > On Tue, Apr 12, 2016 at 4:27 AM, Henri Sivonen <
>> hsivo...@hsivonen.fi>
>> > > wrote:
>> > > >>
>> > > >> On Tue, Apr 12, 2016 at 7:45 AM, Masayuki Nakano <
>> > masay...@d-toybox.com
>> > > >
>> > > >> wrote:
>> > > >> > So, my question is, why do we still have Qt widget in
>> > mozilla-central?
>> > > >> > What
>> > > >> > the reason of keeping it in mozilla-central?
>> > > >>
>> > > >> My understanding is that
>> > > >> https://git.merproject.org/mer-core/qtmozembed/ still uses it. As
>> we
>> > > >> are figuring out how to be more embeddable (see
>> > > >> https://medium.com/@david_bryant/embed-everything-9aeff6911da0 ),
>> > it's
>> > > >> probably a bad time to make life hard for an existing embedding
>> > > >> solution.
>> > > >
>> > > >
>> > > > This doesn't really answer the question. We can't have code in tree
>> > that
>> > > > isn't tested, and isn't used, and has nobody responsible for it.
>> > > >
>> > > > If someone is willing to fix it up and get it tested and included in
>> > the
>> > > > continuous integration process, then that's fine. But "someone might
>> > > want to
>> > > > use it in the future" can't possibly be a legit reason to keep
>> > > substantial
>> > > > bits of code in the tree.
>> > >
>> > > It looked to me like the code is being used *now*.
>> > >
>> > > Raine, does qtmozembed use the Qt widget code from mozilla-central?
>> > >
>> > > --
>> > > Henri Sivonen
>> > > hsivo...@hsivonen.fi
>> > > https://hsivonen.fi/
>> > >
>> > ___
>> > 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

Re: Checkin-needed requests - Please include complete information in the commit message :)

[Ryan VanderMeulen]

FWIW, there's also an MDN page that documents a lot of this as well:
https://developer.mozilla.org/en-US/docs/Mercurial/Using_Mercurial#How_can_I_generate_a_patch_for_somebody_else_to_check-in_for_me.3F

-Ryan

On 7/8/2016 2:32 AM, Carsten Book wrote:

Hi,

someone might not know that doing checkins for checkin-needed request is
not automated yet and completely a fully human task :) (no we Sheriffs are
not bots ;)

It would help us a lot if a checkin needed request would contain complete
Author/Patch information like:


   - Author (use the information from their Bugzilla account if needed)
   with Name *and *Emailadress.
   - Bug number
   - Commit message (keeping in mind that the commit message should be a
   brief description of what the patch is *doing*)
  - Format should be something like "Bug 123456 - Add a null check to
  XYZ to avoid a crash. r=somebody"


And also if there is a specific sequence/dependency you want to checkin the
patches it would help also a lot  if you could make a short comment in the
Bug like please checkin part x then patch y or like first bug 123 then this
bug and then bug 8910.

This would help us a lot :)

Thanks!

- Tomcat



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Treeherder, Task Cluster and Pulse

[Gregory Arndt]

As a follow up, I would like to point out a couple of pieces of information:

mozilla-taskcluster is still operational for scheduling decision tasks and
handling actions from treeherder (cancel/retrigger) for taskcluster tasks.
Only api submission for jobs was turned off and now handled by our new
component, taskcluster-treeherder [1]. At some point the remaining
functionality will be split into separate services leading to the
decomission of mozilla-taskcluster.

Taskcluster tasks have always contained data under task.extra.treeherder,
but now we have a schema [2] published that this data is validated against
and can also be used as a reference.

A new field, 'jobKind', has been added to this section.  This allows a task
to declare what type of task it is and Treeherder can take actions
appropriate for the kind of task that's being reported. Currently the most
notable difference is when a task marked as 'build' fails, it will be
reported to Treeherder as red.  Previously all job failures were reported
orange (testfail) regardless of the job type.  Failed tasks with a jobKind
of test will be reported as orange and any task which does not specify
jobKind or is marked as 'other' will be shown as red.

We made sure that all existing tasks that are being reported could pass
this validation and in the future we will work with task
creators/maintainers at adding more validation constraints for this data.

-Greg


[1] https://github.com/taskcluster/taskcluster-treeherder
[2]
https://schemas.taskcluster.net/taskcluster-treeherder/v1/task-treeherder-config.json#

On Wed, Jul 6, 2016 at 6:43 PM, Cameron Dawson  wrote:

> Tomorrow morning we will be changing how Treeherder gets data from Task
> Cluster.
>
> tl;dr — No action required on your part.  We are changing some things
> under the hood, but everything should look the same.
>
> More Info
> ===
>
> Greg Arndt, Jonas Jensen and I have been working on using Pulse to get
> results to Treeherder rather than Task Cluster posting directly to the
> Treeherder APIs.  This will mean simpler data ingestion with better
> validation.  Huge thanks to Jonas Jensen who came up with the scheme for
> this in the first place and helped me get rolling on it.  Also huge thanks
> to Greg who’s done a ton of fantastic work on the Task Cluster side of this.
>
> We will take this live tomorrow, July 7th around 10am.
>
> What’s going to happen?
> =
>
> The new Fancy-Pants  app that Greg wrote has
> already been posting messages to pulse exchanges for both stage and
> production.  But Treeherder-prod hasn’t been listening.  We will turn on
> Treeherder-prod’s Fancy-Pants ``read_pulse_jobs`` process.  Then push a
> change to the Old-Pants  app that will make it stop
> posting jobs to Treeherder’s API.
>
> You shouldn’t notice anything, but in the unlikely event that you DO,
> please chime in on #treeherder and check in with :camd (me) or :garndt.
>  We’ve been testing this on Treeherder-staging for a month or so and it’s
> been working great.  We hope to continue that trend on prod.  :)
>
> Other benefits
> ==
>
> 1. Other tools can now post data to their own Pulse exchanges, register
> them with Treeherder, and we will pick that data up.  Please submit a bug
> to Treeherder with your exchange information and we will get you set up.
> 2. The submission data will be validated against a JSON-schema <
> https://github.com/mozilla/treeherder/blob/master/schemas/pulse-job.yml>
> to take the guess-work out of submitting to Treeherder.  You should
> validate your own data prior to submission to your exchange.
> 3. Folks playing with Treeherder on your local Vagrant instance can now
> use the read_pulse_jobs management command to ingest Task Cluster data as
> well as BuildBot.
>
> The docs for this are at: https://treeherder.readthedocs.io/pulseload.html
>
> Please let me or Greg Arndt know if you have any questions.
>
> Thanks heaps!  :)
> -Cam
>
> P.S. - Here’s a blog post I wrote about it in the early-stages of planning
> this:
> https://cheshirecam.wordpress.com/2015/09/30/treeherder-loading-data-from-pulse/
> It’s mostly still true.
>
> ___
> dev-tree-management mailing list
> dev-tree-managem...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tree-management
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Feedback needed: Firefox 49 for developers on MDN

[Jean-Yves Perrier]

Hi all!

This is this moment again where Firefox XY for developers is ready for 
review. This time it is Firefox 49 for developers [1]


Please have a look at it, and point to me anything that could be wrong 
or missed.


Thank you all for the help!

[1] Link to the page MDN: 
https://developer.mozilla.org/en-US/Firefox/Releases/49#



--
Jean-Yves Perrier
Senior St. Project Manager, Developer Documentation / MDN Content Lead
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Checkin-needed requests - Please include complete information in the commit message :)

[Carsten Book]

Hi,

someone might not know that doing checkins for checkin-needed request is
not automated yet and completely a fully human task :) (no we Sheriffs are
not bots ;)

It would help us a lot if a checkin needed request would contain complete
Author/Patch information like:


   - Author (use the information from their Bugzilla account if needed)
   with Name *and *Emailadress.
   - Bug number
   - Commit message (keeping in mind that the commit message should be a
   brief description of what the patch is *doing*)
  - Format should be something like "Bug 123456 - Add a null check to
  XYZ to avoid a crash. r=somebody"


And also if there is a specific sequence/dependency you want to checkin the
patches it would help also a lot  if you could make a short comment in the
Bug like please checkin part x then patch y or like first bug 123 then this
bug and then bug 8910.

This would help us a lot :)

Thanks!

- Tomcat
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform