Re: License of test data?

[Mike Hommey]

On Thu, May 17, 2018 at 01:31:43PM -0400, mhoye wrote:
> On 2018-04-24 10:36 AM, mhoye wrote:
> > On 2018-04-24 10:24 AM, David Teller wrote:
> > > What's our policy for this? Are there any restrictions? All the
> > > frameworks I currently have at hand are have either an MIT- or an
> > > MIT-like license, so in theory, we need to copy the license somewhere in
> > > the test repo, right?
> > 
> > I think that this is my question to answer now; I've taken on licensing
> > questions in Gerv's absence. I'm new to this part of the job, so it'll
> > take me a day or two to get the answer; I'll come back to this thread
> > when I have it.
> 
> Well, more than a day or two. The MIT license is fine to include, and we
> have a pile of MIT-licensed code in-tree already.
> 
> Other already-in-tree MPL-2.0 compatible licenses - the "just do it" set,
> basically - include Apache 2.0, BSD 2- and 3-clause, LGPL 2.1 and 3.0, GPL
> 3.0 and the Unicode Consortium's ICU.

The above list is for tests. For things that go in Firefox, it's more
complicated. LGPL have requirements that makes us have to put all LGPL
libraries in a separate dynamic library (liblgpllibs), and GPL can't be
used at all.

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

Re: Removing tinderbox-builds from archive.mozilla.org

[Haik Aftandilian]

On Sun, May 13, 2018 at 8:00 AM, Jean-Yves Avenard 
wrote:

> Hi
> On 12/05/2018 04:47, Boris Zbarsky wrote:
>
>> Just to be clear, when doing a bisect, one _can_ just deal with local
>> builds.  But the point is that then it takes tens of minutes per build as
>> you point out.  So a bisect task that might otherwise take 10-15 minutes
>> total (1 minute per downloaded build) ends up taking hours...
>>
>
> I've found it pretty difficult to build old versions once past a couple of
> months. Different version of rustc, dev tools not yet supported
> (particularly on Windows with requirements to always use the last version
> of Visual Studio
>

​Just a note about using an older version of rustc: the "rustup override"
command can be used to downgrade the rust toolchain for a given repo while
not affecting the version that is used on the rest of the system. That can
be handy when trying to build older trees.

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

Re: License of test data?

[mhoye]

On 2018-04-24 10:36 AM, mhoye wrote:

On 2018-04-24 10:24 AM, David Teller wrote:

What's our policy for this? Are there any restrictions? All the
frameworks I currently have at hand are have either an MIT- or an
MIT-like license, so in theory, we need to copy the license somewhere in
the test repo, right?


I think that this is my question to answer now; I've taken on 
licensing questions in Gerv's absence. I'm new to this part of the 
job, so it'll take me a day or two to get the answer; I'll come back 
to this thread when I have it.


Well, more than a day or two. The MIT license is fine to include, and we 
have a pile of MIT-licensed code in-tree already.


Other already-in-tree MPL-2.0 compatible licenses - the "just do it" 
set, basically - include Apache 2.0, BSD 2- and 3-clause, LGPL 2.1 and 
3.0, GPL 3.0 and the Unicode Consortium's ICU.


We have a handful of oddballs in various places though I think we can 
cull some of them out - the Anti-Grain-Geometry stuff has recently been 
relicensed under the GPL, for example.


For anything not on that list a legal bug is def. the next step.

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

Re: Removing tinderbox-builds from archive.mozilla.org

[Mike Kaply]

Can we move the builds temporarily and see if it affects workflows over a
few months and if not, then remove them?

Mike

On Thu, May 17, 2018 at 9:22 AM, Tom Ritter  wrote:

> I agree with ekr in general, but I would also be curious to discover
> what failures we would experience in practice and how we could
> overcome them.
>
> I think many of the issues experienced with local builds are
> preventable by doing a TC-like build; just build in a docker container
> (for Linux/Mac) and auto-build any toolchains needed. (Which would be
> part of bisect in the cloud automatically.) I've been doing this
> locally lately and it is not a friendly process right now though.
>
> Of course on Windows it's an entirely different story. But one more
> reason to pursue clang-cl builds on Linux ;)
>
> -tom
>
>
> On Tue, May 15, 2018 at 12:53 PM, Randell Jesup 
> wrote:
> >>On 5/11/18 7:06 PM, Gregory Szorc wrote:
> >>> Artifact retention and expiration boils down to a
> >>> trade-off between the cost of storage and the convenience of accessing
> >>> something immediately (as opposed to waiting several dozen minutes to
> >>> populate the cache).
> >>
> >>Just to be clear, when doing a bisect, one _can_ just deal with local
> >>builds.  But the point is that then it takes tens of minutes per build as
> >>you point out.  So a bisect task that might otherwise take 10-15 minutes
> >>total (1 minute per downloaded build) ends up taking hours...
> >
> > Also (as others have pointed out) going too far back (often not that
> > far) may run you into tool differences that break re-building old revs.
> > Hopefully you don't get variable behavior, just a failure-to-build at
> > some point.  I'm not sure how much Rust has made this worse.
> >
> > --
> > Randell Jesup, Mozilla Corp
> > remove "news" for personal email
> > ___
> > 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: Removing tinderbox-builds from archive.mozilla.org

[Tom Ritter]

I agree with ekr in general, but I would also be curious to discover
what failures we would experience in practice and how we could
overcome them.

I think many of the issues experienced with local builds are
preventable by doing a TC-like build; just build in a docker container
(for Linux/Mac) and auto-build any toolchains needed. (Which would be
part of bisect in the cloud automatically.) I've been doing this
locally lately and it is not a friendly process right now though.

Of course on Windows it's an entirely different story. But one more
reason to pursue clang-cl builds on Linux ;)

-tom


On Tue, May 15, 2018 at 12:53 PM, Randell Jesup  wrote:
>>On 5/11/18 7:06 PM, Gregory Szorc wrote:
>>> Artifact retention and expiration boils down to a
>>> trade-off between the cost of storage and the convenience of accessing
>>> something immediately (as opposed to waiting several dozen minutes to
>>> populate the cache).
>>
>>Just to be clear, when doing a bisect, one _can_ just deal with local
>>builds.  But the point is that then it takes tens of minutes per build as
>>you point out.  So a bisect task that might otherwise take 10-15 minutes
>>total (1 minute per downloaded build) ends up taking hours...
>
> Also (as others have pointed out) going too far back (often not that
> far) may run you into tool differences that break re-building old revs.
> Hopefully you don't get variable behavior, just a failure-to-build at
> some point.  I'm not sure how much Rust has made this worse.
>
> --
> Randell Jesup, Mozilla Corp
> remove "news" for personal email
> ___
> 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: PSA: Setting preferences and extensions in test harnesses

[Alessio Placitelli]

2018-05-16 16:52 GMT+02:00 Andrew Halberstadt :

> tl;dr - You can now set prefs and install extensions across multiple
> harnesses by modifying the relevant profile under testing/profiles.
>
>
This is GREAT! Thanks for doing it!


> If you previously would have set a  pref in:
> testing/profiles/prefs_general.js,
>
> Use this instead:
> testing/profiles/unittest/user.js
>
>
> # Overview
>
> I'm currently in the process of consolidating prefs and extensions
> across all our test harnesses into a single shared location
> (testing/profiles
> ). If you
> navigate there you'll find several different
> "profile-like" directories.
>
> Each profile directory has a user.js file for setting prefs, and an
> extensions dir for dropping in extensions. I call these directories
> "profile-like" because they only currently support prefs and
> extensions. Don't expect to be able to add other profile-related
> files (though if there's a need, support for other kinds of profile
> data can be implemented).
>
> You'll also find a 'profiles.json' file, and a 'profile' utility script.
> The
> JSON file is used to map test suites to a list of profile directories to
> apply. For example, mochitest uses the 'common' and 'unittest'
> profiles in that order. Prefs from the latter profiles will overwrite
> prefs from the earlier ones. This means you can either set prefs for
> a single harness (e.g by adding them to the latter profile), or set
> prefs across all harnesses at the same time (e.g by adding them
> to the 'common' profile). Same goes for extensions.
>
> Because prefs are split across multiple directories, and those
> directories can overwrite one another, the 'profile' utility script can
> help you view and compare the contents of a profile. For example:
>
> $ cd testing/profiles
> $ ./profile show mochitest  # dumps all prefs that mochitest will use
>
> You can also diff profiles or sort preference files alphabetically:
>
> $ ./profile diff mochitest talos
> $ ./profile sort mochitest
>
> In the future, I may add a command to automatically set preferences
> in a given list of suites.
>
>
> # Motivations
>
> One great use case is testing the impact prefs and extensions have
> on our performance (and unittests). Simply drop an extension into
> testing/profiles/common/extensions and push to try. It will be
> installed in all of our harnesses (that use this system), including Talos.
>
> Another reason for this change is that it provides more visibility into
> which prefs are set in which harnesses. We can now diff the prefs set
> in various suites to try and reason about whether those differences are
> intentional or omissions.
>
> Lastly, this will make it easier to set prefs. No more hunting around
> the tree looking for preference files. This will help prevent cases
> where a pref was accidentally omitted from a test harness.
>
>
> # Further Work
>
> I'm in the middle of migrating harnesses over to this new system.
> Notably, reftest and xpcshell have not yet been converted, though
> hopefully these will be done soon. There is a long tail of smaller
> harnesses that I might not have time to get around to however.
>
> For current support, just look here:
> https://searchfox.org/mozilla-central/source/testing/
> profiles/profiles.json
>
> Here's the relevant bug tree:
> https://bugzilla.mozilla.org/showdependencytree.cgi?id=
> 1451159_resolved=0
>
> Let me know if you have any questions or concerns,
> Andrew
>
> ___
> 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: How to request documentation for new features or report problems on MDN

[Chris Mills]

Yes, what sheppy said ;-)

Chris Mills
MDN content lead & writers' team manager || Mozilla
developer.mozilla.org || MDN Web Docs
cmi...@mozilla.com || @chrisdavidmills

> On 17 May 2018, at 05:27, Eric Shepherd (Sheppy)  
> wrote:
> 
> Yes. Always, you're welcome to make needed changes yourself. If you want a 
> writer to take a look after you're done, to be sure everything is in the 
> right place (or to double-check your grammar), that's certainly no problem.
> 
> On Wed, May 16, 2018 at 6:40 PM Martin Thomson  wrote:
> Hi Chris,
> 
> I assume that "just fix it" is still a viable alternative to the processes
> you describe.  For small things, that might be easier for all involved.
> On Thu, May 17, 2018 at 5:39 AM Chris Mills  wrote:
> 
> > Hi all,
> 
> > I am sending a mail around to explain how to request MDN documentation
> for new features you are working on (e.g. new web platform features, web
> extensions features, devtools features), or report docs problems. We've had
> a fair few people show a misunderstanding of how this process works
> recently.
> 
> > TL;DR
> > -
> 
> > There are two main ways to ask for docs on MDN:
> 
> > * Requesting docs by adding the "dev-doc-needed" keyword to an
> engineering bug
> > * Reporting problems by filing a bug against the "Developer
> Documentation" product (
> https://bugzilla.mozilla.org/enter_bug.cgi?product=Developer%20Documentation
> )
> 
> > They are not equivalent.
> 
> > * "dev-doc-needed" means "some code in Firefox has changed, and as a
> result the docs need to be updated"
> > * a "Developer Documentation" bug means "some docs on MDN are
> wrong/misleading/incomplete"
> 
> > Requesting docs
> > ---
> 
> > So, if you are working on a bug to add a new feature or update an
> existing feature, and it will require documentation changes, add the
> keyword "dev-doc-needed" to it. This keyword doesn't mean "we will document
> this NOW". It means "we will document this in the future, when appropriate".
> 
> > The way the system works is that when "dev-doc-needed" is put on a bug,
> as soon as that bug is then resolved our system picks it up and then we
> will act on it as appropriate (by documenting the feature, or maybe just
> ignoring it if it was WONTFIX’ed, etc.)
> 
> > Using this system, we are ready to document new features, if and when
> they are needed. Please add "dev-doc-needed" for any such features you are
> working on. It makes our lives much easier. Thanks!
> 
> > Note: You can set "dev-doc-needed" any time, but we will only look at it
> once the bug it's attached to is resolved. Once the bug is resolved we'll
> schedule time to update the docs for it, always aiming to have the docs
> updated before the version of Firefox containing the change is released
> (hopefully before that Firefox is in beta, but we don't always manage that).
> 
> > Note: Feature removal/unship bugs should also have "dev-doc-needed" added
> — these are still changes that require docs updates.
> 
> > Note: We don't add notes in our docs to cover bugs/regressions that crop
> up. These are often shortlived, and we don't have the bandwidth for this.
> 
> > Reporting problems
> > --
> 
> > If you notice a problem of some kind with an MDN doc, such as a doc that:
> 
> > * should really be added to make a resource complete, but is not linked
> to a specific feature addition
> > * is located in the wrong place
> > * contains a code, spelling or grammar error
> > * looks outdated
> > * contains spam
> > * etc.
> 
> > Please file a new bug to report it, under the "Developer Documentation"
> product.
> 
> > We triage these bugs weekly, and prioritise and handle them in a similar
> kind of way to engineering bugs.
> 
> > Important: Don't file "Developer Documentation" bugs for feature
> additions that already being tracked in an engineering bug. Instead, add
> the "dev-doc-needed" keyword to the engineering bug. We've had a few
> duplications recently because of this.
> 
> > Many thanks!
> 
> > Chris Mills
> > MDN content lead & writers' team manager || Mozilla
> > developer.mozilla.org || MDN Web Docs
> > cmi...@mozilla.com || @chrisdavidmills
> 
> > ___
> > 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
> -- 
> 
> Eric Shepherd
> Senior Technical Writer
> Mozilla
> Blog: http://www.bitstampede.com/
> Twitter: http://twitter.com/sheppy
> Check my Availability

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

Re: Proposed W3C Charter: Timed Text Working Group

[L. David Baron]

On Thursday 2018-05-17 10:14 +0200, L. David Baron wrote:
> On Thursday 2018-05-03 16:57 -0700, L. David Baron wrote:
> > On Thursday 2018-05-03 08:56 +0200, Anne van Kesteren wrote:
> > > On Thu, May 3, 2018 at 12:42 AM, L. David Baron  wrote:
> > > >   Timed Text Working Group
> > > >   https://www.w3.org/2018/04/proposed-tt-charter-2018.html
> > > 
> > > What does
> > > 
> > > # The Group is expected to produce annual updates for the Recommendation
> > > # with previously unspecified features.
> > > 
> > > mean?
> > 
> > I think it means that the group is supposed to publish a new
> > Recommendation each year (i.e., do maintenance work on the spec),
> > and can add new features to each one, all within the current
> > charter.  I admit "previously unspecified features" is awkward
> > wording, though.
> 
> My inclination is to abstain from the charter review with the
> following comments:
> 
> -
> 
> There's one thing that's worded in a somewhat strange way in the
> charter.  There's a sentence saying:
>   The Group is expected to produce annual updates for the
>   Recommendation with previously unspecified features.
> I think this is intended to mean that the group is expected to have
> a maintenance process that produces new versions of WebVTT annually,
> and that these new versions may add new features.  It may be worth
> rewording this to avoid the somewhat unclear "previously unspecified
> features".
> 
> We also suggest the other minor fixes:
> 1. https://github.com/w3c/charter-timed-text/pull/30
> 2. fix spelling "Recommandation" -> "Recommendation" (twice)
> 
> -

And since there are some other questions about our implementation
plans, for those questions I've written:

-

The reviewer's organization:
   - intends to review drafts as they are published and send comments.
   - intends to develop experimental implementations and send experience
reports.
   - intends to develop products based on this work.


Comments about the deliverables:
   We expect to review and implement changes to WebVTT at some point; such
work might not be particularly timely relative to when the spec changes are
made.



Comments about implementation schedule:
   We implement WebVTT, although recently our implementation has not been
keeping up with changes in the specification.

-

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Timed Text Working Group

[L. David Baron]

On Thursday 2018-05-03 16:57 -0700, L. David Baron wrote:
> On Thursday 2018-05-03 08:56 +0200, Anne van Kesteren wrote:
> > On Thu, May 3, 2018 at 12:42 AM, L. David Baron  wrote:
> > >   Timed Text Working Group
> > >   https://www.w3.org/2018/04/proposed-tt-charter-2018.html
> > 
> > What does
> > 
> > # The Group is expected to produce annual updates for the Recommendation
> > # with previously unspecified features.
> > 
> > mean?
> 
> I think it means that the group is supposed to publish a new
> Recommendation each year (i.e., do maintenance work on the spec),
> and can add new features to each one, all within the current
> charter.  I admit "previously unspecified features" is awkward
> wording, though.

My inclination is to abstain from the charter review with the
following comments:

-

There's one thing that's worded in a somewhat strange way in the
charter.  There's a sentence saying:
  The Group is expected to produce annual updates for the
  Recommendation with previously unspecified features.
I think this is intended to mean that the group is expected to have
a maintenance process that produces new versions of WebVTT annually,
and that these new versions may add new features.  It may be worth
rewording this to avoid the somewhat unclear "previously unspecified
features".

We also suggest the other minor fixes:
1. https://github.com/w3c/charter-timed-text/pull/30
2. fix spelling "Recommandation" -> "Recommendation" (twice)

-

(I'm suggesting an abstention because I think we support the WebVTT
work but not the TTML/IMSC work.  That said, we also haven't had the
resources to be involved in that work lately.)

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform