Re: Two-stage process for ttml2.html

That would be java and ant itself apparently.

On 14 Nov 2017, at 11:23, Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>> wrote:

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<mailto: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<mailto: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<mailto:glenn@skynav.com>> wrote:
>
>
> On Tue, Nov 14, 2017 at 5:59 AM, Pierre-Anthony Lemieux <pal@sandflow.com<mailto: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<mailto: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<mailto: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<mailto: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<mailto:singer@mac.com>]
>> >>> Gesendet: Montag, 13. November 2017 13:39
>> >>> An: TTWG <public-tt@w3.org<mailto:public-tt@w3.org>>
>> >>> Cc: Philippe Le Hegaret <plh@w3.org<mailto: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<mailto: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<mailto: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<mailto: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.
-----------------------------




----------------------------

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.

---------------------