If we do an auto-reformat I strongly recommend doing it in small chunks. Start with a few files at a time, to minimize risk.
On Fri, May 13, 2016 at 7:21 PM, Shu-yu Guo <s...@mozilla.com> wrote: > First, Bill, I'm flattered by your mention, thank you. > > I am in favor of unifying styles with Gecko, though I have a practical > concern. I am currently in the middle of a frontend rewrite that is an > unwieldy amount of changes. Could I request the re-style to be put off for > a month or three until the rewrite lands? > > Thanks, > > > On Thu, May 12, 2016 at 5:04 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com> > wrote: > >> On 2016-05-12 9:53 AM, Nicolas B. Pierron wrote: >> > The more we empower people for working only on their domain(s) of >> > expertise, the less we would have need for such heroes. Having persons >> > responsible for the integration would help us on that. >> >> As someone who has worked on many parts of the browser, I cannot >> disagree more. Bugs just don't tend to align themselves within >> someone's "domain expertise". I think of bugs which seem to only >> require me to only remember knowledge that I have accrued over the years >> as "easy bugs", and the more I learn about different parts of the >> browser, the more I come across issues that touch on the things that I >> have never learned about before, or things that I haven't learned well >> enough. Those I call "normal bugs". >> >> Also bugs are only one part of our work. I have found out that the more >> parts of the browser I have learned about, the more I have been able to >> work on "cross-functional" things that have benefited the browser as a >> whole, and nowadays these sorts of stuff are commonplace projects that >> we're working on. Take e10s as an example, that project doesn't map at >> all to any of the islands that we have created in our organization >> and/or code base. We need more and more people to be able and willing >> to step out of the little islands, as the whole world has grown much >> smaller now and the islands that maybe we created for good reasons back >> in the day are really just an artifact of the past. >> >> It's true that a successful project requires both specialists and >> generalists, and none of the above means that all people need to be >> generalists. It means that we need to see these little islands >> (SpiderMonkey included) as what they are, remnants of the past simple >> days where we'd get away with pretending to have we have a bunch of >> loosely integrated components that we could make a browser out of. >> (Anyone remember the pre-libxul days where we pretended to have >> "libraries" and whatnot? ;-) >> >> The current reality how web browsers are made don't afford us treating >> our codebase in that way any more. To me, discussions around unifying >> the coding style drill into the heart of this problem: we need to move >> on from having small compartments with people painting the walls to >> their heart's content, and treat the browser as the one unified beast >> that it truly is. Not because it matters how much whitespace we put >> where, but because a unified style paints the walls in a way that urges >> people to stop thinking in terms of small islands, and start thinking in >> terms of Firefox as a whole. >> >> My CDN$0.02 with respect, >> Ehsan >> _______________________________________________ >> dev-tech-js-engine-internals mailing list >> dev-tech-js-engine-internals@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals >> > > > > -- > shu > _______________________________________________ > dev-tech-js-engine-internals mailing list > dev-tech-js-engine-internals@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals _______________________________________________ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
