Re: Two-stage process for ttml2.html

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

I will report on the complexity of the process as I process TTML1 issues.

Best,

-- Pierre

On Mon, Nov 13, 2017 at 10:46 PM, Glenn Adams <glenn@skynav.com> wrote:
>
>
> 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
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>
>> >> >
>> >
>> >
>
>

Received on Tuesday, 14 November 2017 06:57:14 UTC