Tabs and spaces
I've noticed seven moz.build files containing tabs, I assume this is undesirable? -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Tabs and spaces
On 3/2/2014 5:25 AM, Neil wrote: I've noticed seven moz.build files containing tabs, I assume this is undesirable? Yes. We should probably make the moz.build reader error on tabs. -Ted ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Tabs and spaces
On 2014-03-02, 9:12 AM, Ted Mielczarek wrote: On 3/2/2014 5:25 AM, Neil wrote: I've noticed seven moz.build files containing tabs, I assume this is undesirable? Yes. We should probably make the moz.build reader error on tabs. +1, and filed Bug 978582 [1]. Nick [1] https://bugzilla.mozilla.org/show_bug.cgi?id=978582 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Blink removing the concept of user styles?
How much simpler could our style code be if we followed this path? What do the standards and other browser vendors say about this? Horrible idea? Great idea? Mixed? This is in preparation for simplifying the Blink style resolution code by removing the concept of user styles. https://src.chromium.org/viewvc/chrome?revision=234007view=revision - A ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Blink removing the concept of user styles?
On Sunday 2014-03-02 10:58 -0800, Asa Dotzler wrote: How much simpler could our style code be if we followed this path? What do the standards and other browser vendors say about this? Horrible idea? Great idea? Mixed? This is in preparation for simplifying the Blink style resolution code by removing the concept of user styles. https://src.chromium.org/viewvc/chrome?revision=234007view=revision Conceptually, not at all. It would be one fewer item in an array. -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: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Blink removing the concept of user styles?
I am not really sure, but does this mean that addons like Stylish won't work any more ? (or is it some other user styles) On Mon, Mar 3, 2014 at 2:32 AM, Tim timvk...@gmail.com wrote: On Sunday, 2 March 2014 19:58:28 UTC+1, Asa Dotzler wrote: How much simpler could our style code be if we followed this path? What do the standards and other browser vendors say about this? Horrible idea? Great idea? Mixed? This is in preparation for simplifying the Blink style resolution code by removing the concept of user styles. https://src.chromium.org/viewvc/chrome?revision=234007view=revision - A That would be a great reason to move to Chrome. NO THANK YOU ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Girish Sharma B.Tech(H), Civil Engineering, Indian Institute of Technology, Kharagpur ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Changing how build automation interacts with the tree
Hi,
I've watched you guys thinking for an hour ;-)
Some comments from me.
Yes to moving build flows that generate assets into the tree.
Yes to having a way for developers to reproduce what automation does.
Yes to having jobs being executed more on demand than on push, and
having that have idempotent results.
Sceptical on the vision that we'll see the end of inbounds. The
interactions between test results and rebase don't seem to be trivial
enough to me to hope for non-backout always-open trees via auto land.
I'm having an 'oh noes' for single command called by automation. My main
point here is the usefulness of logs generated. When you put all
sequential and parallel tasks into one single wrapper process, you end
up with one big log file on ftp, like today. And if anything happens,
one needs to read that log and reverse engineer which characters in this
log are stdout/stderr, and to which task they belong. I know I can't
tell good from bad in our logs.
OTH, you could have all the structure of the process being exposed in
the automation and its reporting. If something goes wrong, you can tell
the location of the problem in the process right away, you can drill
down to the process task, and its dependencies.
If I think of the problem, I'm thinking along these lines: Let's specify
the process, as a DAG of serialized and parallized tasks, inside the
tree, and have the automation run that as is (*). Offer developers a
console-only hook to that fragment of the complete automation process,
akin to integration tests.
* while using buildbot, parallel tasks would need to be executed
sequentially. I read the recent posts by Taras et al that buildbot isn't
a solid requirement going forward.
A few comments on mozharness. One of the earliest tasks it offered,
IIRC, was multi-locale android builds. Sadly, it happens that it's not
helping those developers that want to create and test multi-locale
builds. It's monolithic deliverable isn't what developers need at the
point when they test multi-locale builds, nor does it blend in to the
developer's setup. Folks like rnewman were glad once I explained how to
avoid using mozharness for their builds. To me that's a sign of an
inadequate level of abstraction.
And, as it's been mentioned all over the call, l10n repacks:
Testing: repacks are hard to test, and they should be. They're designed
to be infallible, so that, no matter what happens in a localization,
they're producing runnable builds. A test is challenged to tell between
a broken localization and a broken build system. We shouldn't
overestimate the amount of errors in the build that end up in a build
bustage, and which of those are actually test failures. And which are
not generating build failures, but are bustages. One example would be
broken locale merge dirs, for example. Anything can be in those, and the
builds build and run fine. They're just not showing the right strings.
More generally, repacks are basically unowned at this point. There's a
bit of ownership in build, in releng, and me, as to how they're done.
There's absolutely nothing as far as reporting goes. The agreement
between John and me was if there's anything odd, file a bug on releng
to dig in.
That's as much as I can get out of my brain into writing, I wish I had
an hour-long video to go back and forth about stuff ;-)
Axel
On 2/28/14, 9:48 PM, Gregory Szorc wrote:
(This is likely off-topic for many dev-platform readers. I was advised
to post here because RelEng monitors dev-platform and I don't like
cross-posting.)
The technical interaction between build automation and mozilla-central
has organically grown into something that's very difficult to maintain
and improve. There is no formal API between automation and
mozilla-central. As a result, we have automation calling into esoteric
or unsupported commands and make targets. Change is difficult because it
must be coordinated with automation changes. Build system maintainers
lack understanding of what is and isn't used in automation. It's
difficult to reproduce what automation does locally.
The current approach slows everyone down, leads to too-frequent breakage
(l10n repacks are a great example), and limits the efficiency of
automation.
I'm elated to state that at a meeting earlier today, we worked out a
solution to these problems! Full details are in bug 978211.
tl;dr we are going to marshal all interaction between automation and the
tree through a mach-like in-tree script. This script will establish a
clear, supported, and auditable API for automation tasks and will
establish a level of indirection allowing the tree to change without
requiring corresponding changes to automation.
Some of the benefits of this approach include:
* Abstracting the build backend away from automation. The tree will
choose GNU make, pymake, mozmake, Tup, etc depending on what it knows is
best. Currently, automation has {make, pymake, mozmake} hard-coded.
Re: Blink removing the concept of user styles?
This most dumb idea ever, ATM we still can do with Firefox what we like, if I don't like Australis i can change that easy, if You remove this opportunity than simple close Mozilla, link Chrome download on main side and forget about it... ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Blink removing the concept of user styles?
On 03/02/2014 01:58 PM, Asa Dotzler wrote: How much simpler could our style code be if we followed this path? What do the standards and other browser vendors say about this? Horrible idea? Great idea? Mixed? This is in preparation for simplifying the Blink style resolution code by removing the concept of user styles. The checkin you refer to removed support for the equivalent of our userContent.css -- that is, a bare CSS file dropped into the profile directory, which is taken into account in the cascade. They were watching that file for changes mid-execution, which makes their support code more complicated than ours - we only read userContent.css on startup. It is not clear to me from that whether they removed (or intend to remove) support for *user styles* in general - that is, what the CSS Cascade draft calls Important user declarations and Normal user declarations. [1] The observation that extensions are a better way to do this sort of thing suggests not: such extensions would need a hook point into the core, which would be functionally equivalent to user styles. I would take the Stylish extension's 750,000 installs as a lower bound on the demand for *some* persistent mechanism whereby each user can adjust site styles to their liking, and to me that is enough to conclude that we should keep what we have. zw [1] http://dev.w3.org/csswg/css-cascade/#cascading ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Blink removing the concept of user styles?
On 3/2/2014 4:02 PM, Tim wrote: That would be a great reason to move to Chrome. NO THANK YOU To point out the obvious, your reply is in response to Asa pointing out that Blink is removing this feature, which means it will no longer exist in Chrome, therefore your statement makes no sense. -Ted ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
