Fwd: Re: Cleaning up webrtc spec

I forgot to add this to Thursday's agenda.

I think we should do what he suggests - either ask him to make a PR for
us, or do the equivalent ourselves.


-------- Forwarded Message --------
Subject:  Re: Cleaning up webrtc spec
Resent-Date:  Fri, 04 Sep 2015 17:29:28 +0000
Resent-From:  public-webrtc-editors@w3.org
Date:  Fri, 4 Sep 2015 10:28:59 -0700
From:  Martin Thomson <martin.thomson@gmail.com>
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

Last email on the subject:

I am willing to port the same change I made to the push API to the
webrtc spec(s).


This puts the onus on authors of pull requests for keeping things tidies.

On 31 August 2015 at 22:12, Martin Thomson <martin.thomson@gmail.com> wrote:
> 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 Sunday, 20 September 2015 17:24:27 UTC