Re: Two-stage process for ttml2.html

> However, this often requires a manual merge edit of ttml2.html when there has been an intervening regeneration of ttml2.html on gh-pages.

Can't the workflow can be:

- merge from gh-pages into the PR branch (to account for any
modifications made to ttml2.xml since the PR was branched)
- regenerate ttml2.html on the PR branch
- merge PR branch into gh-pages

Best,

-- Pierre

On Mon, Nov 13, 2017 at 10:09 PM, Glenn Adams <glenn@skynav.com> wrote:
>
>
> On Tue, Nov 14, 2017 at 5:59 AM, Pierre-Anthony Lemieux <pal@sandflow.com>
> wrote:
>>
>> > 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?
>
>
> It can, and we have done it on occasion in the past. However, this often
> requires a manual merge edit of ttml2.html when there has been an
> intervening regeneration of ttml2.html on gh-pages. Alternatively, it
> requires ignoring changes in gh-pages and using only a new ttml2.html
> regenerated in the PR branch, which has the possible danger of losing merged
> data in ttml2.html.
>
> As a consequence, we have generally only pushed changes to ttml2.xml and
> then performed the ED regeneration process directly in the gh-pages branch.
> There are also some other related issues regarding the regeneration of
> schema archive files, so that we have regenerated these on the gh-pages
> branch as well rather than in a 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:16:54 UTC