Two-stage process for ttml2.html

> is the use of a two stage commit process, whereby we push primary changes to ttml2.xml
> and then use a separate process to build and push an updated ttml2.html.

Why can't ttml2.html be generated on the PR branch?

Best,

-- Pierre

On Mon, Nov 13, 2017 at 9:50 PM, Glenn Adams <glenn@skynav.com> wrote:
> Just to be clear where I stand, I have no objection to this new policy for
> substantive issues; however, I do have problems with its application to
> editorial issues and other types of upkeep and maintenance pushes. One
> particular aspect of TTML{1,2} editorial process that doesn't hold for the
> other repositories is the use of a two stage commit process, whereby we push
> primary changes to ttml2.xml and then use a separate process to build and
> push an updated ttml2.html. In general, this has been done via multiple
> commits into gh-pages (and master before that). Indeed, an approximately 50%
> of the commits are to regenerate the html file. The proposed new process
> will require that every push go through a PR and review. For TTML repos,
> this means that we may see many PRs that do nothing other than regenerate
> the ED. IMO, this adds a considerable burden to the editing process that
> those who don't work with this process fail to appreciate.
>
>
> On Tue, Nov 14, 2017 at 5:27 AM, David Ronca <dronca@netflix.com> wrote:
>>
>> Perhaps everyone can agree that this is a good model going forward.  It is
>> troubling, however, that we are debating a change that was already made,
>> apparently with very little input from the working group.
>>
>> David
>>
>> On Mon, Nov 13, 2017 at 8:33 PM, <tai@irt.de> wrote:
>>>
>>> I support the new policy to require a pull request review before merging.
>>> It is a common practice in software development and helps keeping the
>>> quality of the code. The same applies to standards. We may find possible
>>> blockers beforehand and encourage group members to participate in the
>>> editing process.
>>>
>>> We can reassess the decision after some months of practical experience.
>>>
>>> Best regards,
>>>
>>> Andreas
>>> -----Ursprüngliche Nachricht-----
>>> Von: David Singer [mailto:singer@mac.com]
>>> Gesendet: Montag, 13. November 2017 13:39
>>> An: TTWG <public-tt@w3.org>
>>> Cc: Philippe Le Hegaret <plh@w3.org>
>>> Betreff: Re: Protected Policy on Repository Merging Process
>>>
>>> I am on the hook to do approvals for the VTT spec. (one of the approvers)
>>> and indeed it’s an easy task if the edit truly is editorial. But in another
>>> group I am in, someone realized that an edit that the editor thought
>>> editorial actually did have implications (both for function and readability)
>>> and we had to revert, which was more painful.
>>>
>>> CSS at least is considering (may already have decided) to move to a “no
>>> direct edits” model, where  every change to a document under WG change
>>> management is done via Pull Requests. Under these circumstances, the editor
>>> would normally have their own GitHub repo that represents their best
>>> thinking and they’d PR into the group repo, which means that the editor’s
>>> latest version of the document is in their repo, and at least one other
>>> person has confirmed the changes to the WD in the group’s repo.
>>>
>>> I don’t think either of these are terribly burdensome (not nearly as
>>> burdensome as some other things we have to do).
>>>
>>> > On Nov 11, 2017, at 1:27 , Glenn Adams <glenn@skynav.com> wrote:
>>> >
>>> > Regarding the following, I propose the following:
>>> >       • that a special label, "protected", be used to designate whether
>>> > an issue is subject to commit protection control, where any member can add
>>> > this label, but only the chair (or his delegate) may remove it, and where it
>>> > is understood that this label is intended to be applied only to
>>> > non-editorial or non-trivial issues that should be subject to a reviewed PR
>>> > process;
>>> >       • that application of protection semantics be restricted to those
>>> > issues having the protected label; that is, if an issue has the protected
>>> > label, then a commit to gh-pages is not permitted unless another member
>>> > approves the review of a PR associated with the issue;
>>> >       • that the non-consensus policy change recently imposed to effect
>>> > commit protection semantics be reversed and deferred until the above
>>> > two points are implemented; G.
>>> >
>>> > On Fri, Nov 10, 2017 at 12:52 PM, Glenn Adams <glenn@skynav.com> wrote:
>>> > I just discovered that, as an editor, I cannot make a trivial editorial
>>> > change to the TTML2 repository without an approved review by another member.
>>> >
>>> > This new policy was apparently established without discussion or review
>>> > by the group, and directly contravenes existing group practice and standing
>>> > policies.
>>> >
>>> > For example, in the standing (group approved) TTML2 Editing Process,
>>> > we have [1], which states
>>> >
>>> > The editor may merge a PR, with or without changes, at any time,
>>> > subject to the review period guidelines described above. The editor may
>>> > delegate the merging of a PR to the creator of the PR or to another party.
>>> > If merging a PR has been delegated, then the editor and delegatee should
>>> > coordinate mergers to avoid unintended conflicts.
>>> >
>>> > If a PR merge is effected prior to the end of the nominal review
>>> > period, then a Merge Early label must be applied to the associated issue.
>>> >
>>> > PR merges occur only from a PR branch to the gh-pages (default) branch.
>>> >
>>> > [1]
>>> > https://github.com/w3c/ttml2/blob/gh-pages/EDITING.md#pull-request-mer
>>> > ging
>>> >
>>> > Furthermore, we have [2]:
>>> >
>>> > This project operates on the principles of lazy consensus, a reasonable
>>> > description of which can be found at Apache Rave™ Project.
>>> >
>>> > [2]
>>> > https://github.com/w3c/ttml2/blob/gh-pages/EDITING.md#lazy-consensus-a
>>> > pplies
>>> >
>>> > The new, unapproved policy, contravenes the application of the approved
>>> > and standing process in a number of ways, including
>>> >       • imposes a review-then-commit (RTC) policy on an existing
>>> > commit-then-review (CTR) policy;
>>> >       • eliminates editor prerogative to perform merge, specifically,
>>> > editorial or trivial changes;
>>> >       • effectively forces every change whatsoever, no matter how
>>> > trivial, to require going through a pull request (PR) process.
>>> > This change will have an immediate deleterious effect on the nature and
>>> > timeliness of performing common editor tasks. I predict it may result in a
>>> > 50 to 100% delay of schedule in the process of going from WD to REC. It will
>>> > most certainly push out the TTML2 specification's schedule in significant
>>> > manner.
>>> >
>>> > Finally, this change is, in my opinion, a vote of no confidence for all
>>> > editors, in the sense that it removes a default level of trust in editors
>>> > that has applied for the history of this group.
>>> >
>>> > Consequently, I strongly object to this change, and ask the chair and
>>> > W3M to reconsider this draconian, and unapproved top-down mandatory policy
>>> > change.
>>> >
>>> > G.
>>> >
>>> >
>>> >
>>> >
>>> >
>>>
>>> David Singer
>>>
>>> singer@mac.com
>>>
>>>
>>>
>>>
>>>
>>
>

Received on Tuesday, 14 November 2017 06:00:13 UTC