Re: Errata for Touch Events REC

Patrick just pointed out that I somehow botched this and missed some recent
v1-errata commits in the merge.  Sorry, not sure how that happened!  It was
easy to fix here
<https://github.com/w3c/touch-events/commit/4082863cc382d40c378b1d6cef00e2abdd405e02>
.

Rick

On Wed, Jul 8, 2015 at 3:39 PM, Rick Byers <rbyers@chromium.org> wrote:

>
>
> On Thu, Jul 2, 2015 at 8:10 PM, Rick Byers <rbyers@google.com> wrote:
>
>> On Fri, Apr 17, 2015 at 10:35 AM, Rick Byers <rbyers@google.com> wrote:
>>
>>> On Fri, Apr 17, 2015 at 8:35 AM, Arthur Barstow <art.barstow@gmail.com>
>>> wrote:
>>>
>>>> On 4/14/15 9:10 AM, Rick Byers wrote:
>>>>
>>>>> On Tue, Apr 14, 2015 at 7:48 AM, Arthur Barstow <art.barstow@gmail.com
>>>>> <mailto:art.barstow@gmail.com>> wrote:
>>>>>
>>>>>     On 4/13/15 5:21 PM, Rick Byers wrote:
>>>>>
>>>>>         On Mon, Apr 13, 2015 at 5:13 PM, Arthur Barstow
>>>>>         <art.barstow@gmail.com <mailto:art.barstow@gmail.com>
>>>>>         <mailto:art.barstow@gmail.com <mailto:art.barstow@gmail.com>>>
>>>>>         wrote:
>>>>>
>>>>>             Hi All,
>>>>>
>>>>>             The errata for the Touch Events REC [1] is still mostly
>>>>>         empty and
>>>>>             it contains what I would characterize as a somewhat
>>>>> surprising
>>>>>             statement:
>>>>>
>>>>>             [[
>>>>>                    <
>>>>> http://www.w3.org/TR/2013/REC-touch-events-20131010/REC-touch-events-20131010-errata.html
>>>>> >
>>>>>             ...
>>>>>
>>>>>             An updated specification will be located at WebPlatform
>>>>> Specs.
>>>>>             ]]
>>>>>
>>>>>             I say "surprising" because I don't recall us agreeing to
>>>>>         publish
>>>>>             an update at specs.webplatform.org
>>>>>         <http://specs.webplatform.org> <http://specs.webplatform.org>.
>>>>>
>>>>>             Would someone please clarify?
>>>>>
>>>>>
>>>>>         IIRC Doug said that was the new preferred path for publishing
>>>>>         errata the last time we discussed the errata process on a
>>>>>         call.  Perhaps "updated specification" is misleading though :-)
>>>>>
>>>>>             Anyhow, what, if anything should be added to the errata
>>>>>         document?
>>>>>             Does the CG have consensus about text for the errata
>>>>> document?
>>>>>             Alternatively, perhaps the errata document could link to a
>>>>>         version
>>>>>             of the spec that is the REC + agreed errata text (all
>>>>>         inlined, and
>>>>>             perhaps styled such all of the changes from the REC are
>>>>> very
>>>>>             clearly identifiable and enumerated in the Changes Since
>>>>>         last Pub
>>>>>             section)?
>>>>>
>>>>>             Personally, I think having a document that is the REC +
>>>>> agreed
>>>>>             errata changes is more useful than adding text to the
>>>>>         errata document.
>>>>>
>>>>>
>>>>>         I like that plan too.  From our recent call though it sounds
>>>>>         like some of the 'errata' changes we've made may need to be
>>>>>         considered normative.  Eg. fractional co-ordinates.  That one
>>>>>         change alone is important enough to me (and, IMHO, the
>>>>>         platform) that I wouldn't want to let it fall through the
>>>>>         cracks.  So perhaps we should be talking more about publishing
>>>>>         a minor v1.1 update instead of worrying about errata?
>>>>>
>>>>>
>>>>>     Yes, I think the consensus is to put all of the changes in a
>>>>>     single document and then Doug and I (and anyone interested in the
>>>>>     `sausage making`) will figure out how to get that doc published as
>>>>>     a Technical Report.
>>>>>
>>>>>     BTW, what is the rough status and plan of that document (perhaps
>>>>>     we should call it TE Level 2)? Have all of the changes we want to
>>>>>     make been added to one of the branches (and if yes, which
>>>>>     branch)?  Do we want to block publication pending more feedback
>>>>>     from implementations and deployment? I noticed there are some open
>>>>>     issues <https://github.com/w3c/touch-events/issues>.
>>>>>
>>>>>
>>>>> We've got two branches/documents at the moment - v1-errata and
>>>>> 'master' which has the TEE.  It sounds like we should merge the errata and
>>>>> TEE back into a single document in master (returning us to single-branch
>>>>> sanity), is that right?  I'd want to make sure we have consensus on this
>>>>> before making the change.
>>>>>
>>>>
>>>> Yes, doing that merge seems right to me.
>>>
>>>
>>>> Re getting consensus, perhaps the simplest thing to do is to create a
>>>> PR and then announce it with a short-ish review cycle that will result in
>>>> merging the PR if no one raises any objections by the end of the cycle.
>>>
>>>
>>> Ok, I will do that sometime soon
>>>
>>
>> I finally got around to doing this (sorry for the delay):
>> https://github.com/w3c/touch-events/pull/14.
>>
>> The diff is a little messed up because it represents merging all the
>> v1-erata work into master (when really it's mostly about adding a couple
>> paragraphs from the TEE into the v1-erata document).  More useful is to
>> look just at the diff of touchevents.html here
>> <https://github.com/w3c/touch-events/compare/v1-errata...RByers:merged-v2>.
>> You can see the final result here
>> <http://rawgit.com/RByers/touch-events/merged-v2/touchevents.html>.
>>
>> If we approve this, then I can follow-up with a big branch clean-up -
>> closing v1-eratta and renaming 'master' to gh-pages so that we'll
>> effectively have the same simple setup as for pointerevents.
>>
>> Thoughts?
>>
>
> I've now merged this (with some small improvements suggested by Patrick).
> Happy to make additional improvements as a follow-up if there's any other
> feedback.
>
> There are still a few outstanding issues / changes.  I haven't been in any
>>>>> big rush to get them done (as I don't currently have any impl work blocked
>>>>> on further spec changes), but perhaps I should be making that a priority?
>>>>>
>>>>
>>>> If the REC being out of date is causing problems (for developers,
>>>> implementers, etc.), then I would say, yes, getting a new TR published is
>>>> something we should do sooner rather than later.
>>>>
>>>
>>> I haven't seen any concrete evidence that this is causing problems for
>>> people (but there is always random confusion about TE behavior which may be
>>> eased by some of the editorial changes we've made).
>>>
>>> -ArtB
>>>>
>>>>
>>>>
>>>
>>
>

Received on Wednesday, 8 July 2015 20:31:34 UTC