Re: Two-stage process for ttml2.html

On Tue, Nov 14, 2017 at 6:16 AM, Pierre-Anthony Lemieux <pal@sandflow.com>
wrote:

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

That has basically been the process when I have chosen to regenerate in the
PR branch. It still entails additional overhead, however, since one has to
manually merge from gh-pages to the PR branch using command line
processing, regenerate ED in PR branch, and then merge back to gh-pages,
which in some cases again must be done manually.

The bottom line for me is that the new process will require non-trivial
additional overhead (and therefore time) that had not been previously
required. Furthermore, nobody asked the group if this process was
acceptable or not before imposing it on us.

It also raises other unaddressed issues, for instance, if one can find a
reviewer to approve a PR, then one can still push a commit even when there
are outstanding unresolved issues or objections to the PR. One might hope
the other reviewer would hesitate to approve in such a case, but they are
not required to do so, and nothing in the github process will prevent that
from happening. So the idea that having another member approve a PR somehow
makes the process safer is just wishful thinking.


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