On Tue, Jul 14, 2015 at 9:06 AM, David Major <dma...@mozilla.com> wrote:
> May I request that the major parts of this not happen until we have a > blame that can "see through" such changes. > > Last I checked, gps had some ideas in that space but lacked time to > implement. > I spoke to a Mercurial maintainer about some of my ideas and the feature would be welcome upstream. However, there isn't enough time to land for Mercurial 3.5 (code freeze this week), so we'd have to wait until Mercurial 3.6 (November 1 release date) at the earliest. That being said, every other organizations in the world is using the same or similar tools and is faced with similar challenges. Lack of a commit-skipping feature doesn't hinder other organizations from performing major refactorings. So while I'd love to make the tools better, I don't think waiting on the tools should be a blocker to mass reformatting the tree. While I'm here, if anyone has suggestions for quick fixes to https://hg.mozilla.org/'s HTML output, those are relatively easy to make. Please file bugs against Developer Services :: hg.mozilla.org if you have ideas! And, if you want to hack on improvements yourself, https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmo/contributing.html#hacking-the-theming tells you how. I reckon we could come up with enough small changes to hold us over until commit skipping in blame is implemented. > > On Wed, Jul 15, 2015, at 03:23 AM, Benjamin Smedberg wrote: > > > > > > On 7/8/2015 7:31 AM, Nathan Froyd wrote: > > > If somebody is willing to do the formatting, I'm willing to do the > > > review. I think the thread has reached the point of people repeating > > > ad nauseum what was already said earlier in the thread, so it's time > > > for a decision. Benjamin? > > > > Aww, I was avoiding getting into this thread. > > > > I personally have no strong preference, and our existing community is > > pretty deeply divided. I doubt we're going to come to consensus here, > > and this is a pretty tough decision to make on its own. I do believe > > that consistency trumps module/personal preference in terms of coding > > style. > > > > The argument I am most sympathetic to is that this convention is a > > barrier to new contributors. Making new contributors productive, both > > employees and volunteers, is a very good reason to choose one style over > > another. > > > > Given that premise, we shouldn't just change aArgument; we should adopt > > the Google C++ style guide wholesale: > > > > * names_with_underscores > > * members_with_trailing_ > > * no more ns prefix > > > > There is good research that underscore_names are more readable, and many > > of these will be more familiar to new contributors. Also we have a fair > > bit of shared code with Google. > > > > If there is a decision to be made here, I'd like to make this RFC: > > > > * switch our codebase wholesale to the Google C++ style guide > > > > With the following implementation plan: > > > > * For now, code should continue to be written in the current style with > > aFoo, mFoo, and camelCase. > > * get our code -Wshadow clean > > * Ask poiru to investigate auto-renaming of our variables including > > mFoo, aFoo, and camelCase to the google-standard local variable names. > > * Do not make any changes to the style guide or standard practice until > > we're comfortable that we can do automatic changes. > > * Make the automatic changes and change our style guide at roughly the > > same time. > > * Go back and deal with class names (nsFoo) as a separate/later pass. > > > > --BDS > > > > _______________________________________________ > > 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
