Re: Cleaning up webrtc spec

Happy to do so.  I will wait until I learn what Dom is up to, so that
we don't end up replicating work.  I have a PR on the -fromelement
spec already that can be trivially ported, but Dom is working on
something better.

On 25 September 2015 at 01:48, Harald Alvestrand <harald@alvestrand.no> wrote:
> Martin,
>
> we've procrastinated on this subject for quite a bit, but seem to have
> agreement now.
> If you're still willing - can you prepare a PR to put this into effect
> on the mediacapture-main repo?
>
> Once we've stumbled in the usual ways over that (and once TPAC is over),
> we can apply it to other repos too, unless we find new reasons not to.
>
> Harald
>
>
> On 09/04/2015 07:28 PM, Martin Thomson wrote:
>> Last email on the subject:
>>
>> I am willing to port the same change I made to the push API to the
>> webrtc spec(s).
>>
>> https://github.com/w3c/push-api/pull/162
>>
>> 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 Friday, 25 September 2015 16:37:54 UTC