Re: Two-stage process for ttml2.html

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
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >
>