Re: Two-stage process for ttml2.html

All the tools used by the ant validate and generate targets (and any they
refer to, transitively) would be necessary on whatever platform runs these
steps.

On Tue, Nov 14, 2017 at 10:26 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>
wrote:

> We probably need two further things on the ttml1 and ttml2 process:
>
> 1. PR check that runs  `ant validate` to check the XML is valid both on
> the pre-merge PR branch and on the result of the merge with the publish
> (gh-pages) branch - if either fails validation, the PR should not be
> mergeable.
> 2. Post-merge step in the publish (gh-pages) branch that runs the relevant
> ant commands to regenerate the html and the schemas. I think it is probably
> just `ant` with no additional commands.
>
> I'm not sure what the best way to execute these is for w3c - in other
> repos I would use a continuous integration/deployment service like travis.
>
> @plh, what choices do we have here?
>
> kind regards,
>
> Nigel
>
>
> ________________________________________
> From: Pierre-Anthony Lemieux [pal@sandflow.com]
> Sent: 14 November 2017 06:16
> To: Glenn Adams
> Cc: David Ronca; Andreas Tai; David Singer; TTWG; Philippe Le Hegaret
> Subject: 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
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>
> >> >
> >
> >
>
>
>
> -----------------------------
> http://www.bbc.co.uk
> This e-mail (and any attachments) is confidential and
> may contain personal views which are not the views of the BBC unless
> specifically stated.
> If you have received it in
> error, please delete it from your system.
> Do not use, copy or disclose the
> information in any way nor act in reliance on it and notify the sender
> immediately.
> Please note that the BBC monitors e-mails
> sent or received.
> Further communication will signify your consent to
> this.
> -----------------------------
>