- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Mon, 31 Aug 2015 22:12:58 -0700
- To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
- Cc: Harald Alvestrand <hta@google.com>, Stefan Håkansson <stefan.lk.hakansson@ericsson.com>, Dominique Hazaël-Massieux <dom@w3.org>, "public-webrtc-editors@w3.org" <public-webrtc-editors@w3.org>, Adam Bergkvist <adam.bergkvist@ericsson.com>
That discipline wouldn't be necessary if you maintained a regimen of cleanup. All the other specs I've worked on have remained clean and it makes the editor's job easier: For instance, https://github.com/w3c/push-api/pull/148 On 31 August 2015 at 16:20, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote: > > I really do my best not to reflow paragraphs (or make gratuitous whitespace changes) as it makes changes much harder to review changes. But we were trying to tidy / reflow right after each release. Its fair to point out that this is partially because github is not a great review tool but it is the one we are using. > > >> On Aug 28, 2015, at 9:37 AM, Martin Thomson <martin.thomson@gmail.com> wrote: >> >> That isn't as big a problem if the baseline and the change are tidy'd. >> >> The same problem exists if you reflow paragraphs. The way you avoid that is to put the tidy changes in a separate commit. >> >> Note that part of this would be to generate automatic reports for editors and people generating pull requests if they need to tidy up. >> >> On Aug 27, 2015 11:45 PM, "Harald Alvestrand" <hta@google.com> wrote: >> the disadvantage of having tidy done every time is that PRs that make structural changes get very hard to review because of the whitespace noise. We should recommend that the tidy result be in a separate commit if we do this. >> >> (it also messes up the blamelists, but we hardly ever look at those, so not a big loss.) >> >> >> On Fri, Aug 28, 2015 at 8:32 AM, Harald Alvestrand <hta@google.com> wrote: >> +rest of editors team >> >> I think "always run tidy" (or make the PR look as if it has been run) is a good approach. >> >> >> On Fri, Aug 28, 2015 at 12:07 AM, Martin Thomson <martin.thomson@gmail.com> wrote: >> I just started on a pull request again today and was >> shocked^Wunsurprised at the poor state the spec is in. I had an idea >> for stopping the rot that I thought that I would share. >> >> We already have a tidy configuration. Also, tidy returns an error >> status if it makes any changes when run. Therefore, simply run tidy >> as part of the travis checks, maybe with a nice error message >> explaining how to run tidy and clean up the PR. >> >> I think that's all that is needed from the tooling end, which should >> be simple enough to setup. I can generate a pull request if this is >> acceptable. >> >> n.b., I plan to do this for other specs that I edit anyway. >> >> As for outstanding pull requests that are in progress, after running >> tidy on the master branch, the fixup is relatively simple. >> >> git checkout -b prbranch2 origin/master >> git checkout prbranch webrtc.html >> make tidy >> git commit -C prbranch webrtc.html >> git checkout prbranch >> git reset --hard prbranch2 >> git branch -d prbranch2 >> git push -f mine prbranch >> >> (This just looks like a rebase and squash of the branch when it is done.) >> >> >
Received on Tuesday, 1 September 2015 05:13:28 UTC