An update of the static analyzers efforts

[Sylvestre Ledru]

Hello,

Last September, I wrote a summary about the ongoing efforts on static
analyzers [1].

I am glad to share some more good news.
Andi (also known as Bogdan) joined the Softvision team a few weeks ago
to help us with this project.

We have three main goals:
* manage the new issues found by the static analyzers
* deal with the backlog of defects found by the static analyzers
(coverity, scan-build, infer, etc).
This means reporting bugs with patches, ignoring false positives, etc
We are using these two meta bugs to keep track of the changes:
   - scan-build/clang analyzer -
https://bugzilla.mozilla.org/show_bug.cgi?id=712350
   - coverity - https://bugzilla.mozilla.org/show_bug.cgi?id=1230156
* develop a better understanding of the quality of each checkers. By
nature, checkers in static analyzers have
different false positives ratio. As we plan to integrate more these
tools in our workflow, we want to know which
checkers we can trust (or not!).

Of course, this is done in parallel of Ehsan's efforts. This is a
complementary project.

Cheers,
Sylvestre

[1]
https://groups.google.com/forum/embed/#!topic/mozilla.dev.platform/VO2rGCSRgNA
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Improving blame in Mercurial

[Boris Zbarsky]

On 12/11/15 6:17 PM, Gregory Szorc wrote:

If you have ideas for making the blame/annotate functionality better,
please capture them at https://www.mercurial-scm.org/wiki/BlamePlan


I went to add stuff, and it was all already there.  ;)


(Relatedly, I know a lot of you want a Mercurial repo with CVS history to
facilitate archeology. I hope to have that formally established in Q1. Stay
tuned.)


You rock.

-Boris

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

Improving blame in Mercurial

[Gregory Szorc]

As Mitchell announced the other night, Mercurial is being awarded a MOSS
grant to improve its blame/annotate functionality. Blame has been cited by
a number of Mozillians as something that they would love to see improved
and the MOSS grant provides the Mercurial Project the means to make it
happen.

If you have ideas for making the blame/annotate functionality better,
please capture them at https://www.mercurial-scm.org/wiki/BlamePlan or let
me know by replying to this message. Your feedback will be used to drive
what improvements Mercurial makes.

(Relatedly, I know a lot of you want a Mercurial repo with CVS history to
facilitate archeology. I hope to have that formally established in Q1. Stay
tuned.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Improving blame in Mercurial

[Xidorn Quan]

On Fri, Dec 11, 2015 at 6:17 PM, Gregory Szorc  wrote:
> If you have ideas for making the blame/annotate functionality better, please
> capture them at https://www.mercurial-scm.org/wiki/BlamePlan or let me know
> by replying to this message. Your feedback will be used to drive what
> improvements Mercurial makes.

I wonder whether it is possible to make blame run in parallel to make
it even faster? Potential method like, split the whole history into X
slices, then do blame independently on each slice, then merge the
result. (As it seems to be a computation intensive task, GIL could be
a real issue, while spawn new processes may not be worth on Windows.)

(I also wonder whether it is possible to make rebase run in parallel,
because I have a nontrivial local tree contains WIP patches (even old
ones I'm not currently working on), and I rebase all of them almost
everyday which always takes some time. However, I guess it is probably
infeasible because rebase mutates the working directory. I probably
should just shelve them, although keep rebasing them may make it
easier to track related changes.)

In addition, I think it would be good to add a command line parameter
on blame to continue previous blame on the ancestor of specified rev.
It isn't always that useful, because you can always just press up
arrow and add/change "-r". But it could be extremely useful if it
correctly handles moved files, since otherwise you would need to
manually input the original path to continue. (Hopefully the "hgweb
links to ancestor's blame" covers this case as well.)

I'm not quite sure what does "Keyboard shortcuts on hgweb" section
mean. It doesn't seem to me adding shortcuts to the blame page makes
sense. But it does make sense to make the file browsing page work like
local file managers or command line path autocompletion when pressing
letter keys. If it is what this section means, I guess it could
probably be described more clearly.

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

Re: Intent to disable service workers in 45 ESR

[Ben Kelly]

Just to clarify, since some people asked:

Firefox 44 = SW enabled
Firefox 45 = SW enabled
Firefox 45 ESR = SW disabled

Only the ESR channel will be disabled.  Normal 45 installs will have the 
feature enabled.

Sorry for any confusion.

Ben

> On Dec 11, 2015, at 2:47 PM, Ben Kelly  wrote:
> 
> Hello,
> 
> We are currently planning to ship service workers in firefox 44 on both 
> desktop and android.  AFAIK, the next ESR is going to be firefox 45.  We plan 
> to disable service workers on all platforms for the ESR release.
> 
>   https://bugzilla.mozilla.org/show_bug.cgi?id=1232029
> 
> We're doing this for a couple reasons:
> 
> 1) Our implementation is likely to change in significant ways in the next few 
> months that will make it quite hard to perform uplifts.
> 2) The spec is still changing; sometimes in significant ways.
> 
> We feel freezing the current service worker API in an ESR will create too 
> many compat issues over the next 9 months or so.  Therefore we plan to enable 
> the feature only in our evergreen release branches.
> 
> Please let us know if there are any concerns.
> 
> Thank you.
> 
> Ben
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Improving blame in Mercurial

[Joshua Cranmer ]

On 12/11/2015 5:17 PM, Gregory Szorc wrote:

If you have ideas for making the blame/annotate functionality better,
please capture them at https://www.mercurial-scm.org/wiki/BlamePlan or let
me know by replying to this message. Your feedback will be used to drive
what improvements Mercurial makes.


A "reverse blame" feature that shows when a line in an old revision was 
deleted or changed in a newer revision is something I've desperately wanted.

(Relatedly, I know a lot of you want a Mercurial repo with CVS history to
facilitate archeology. I hope to have that formally established in Q1. Stay
tuned.)


Are you planning on letting comm-central attach to the CVS history as well?

--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

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

Intent to disable service workers in 45 ESR

[Ben Kelly]

Hello,

We are currently planning to ship service workers in firefox 44 on both
desktop and android.  AFAIK, the next ESR is going to be firefox 45.  We
plan to disable service workers on all platforms for the ESR release.

  https://bugzilla.mozilla.org/show_bug.cgi?id=1232029

We're doing this for a couple reasons:

1) Our implementation is likely to change in significant ways in the next
few months that will make it quite hard to perform uplifts.
2) The spec is still changing; sometimes in significant ways.

We feel freezing the current service worker API in an ESR will create too
many compat issues over the next 9 months or so.  Therefore we plan to
enable the feature only in our evergreen release branches.

Please let us know if there are any concerns.

Thank you.

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