Re: Two-stage process for ttml2.html

plus xjc plus relevant jar files (e.g., jing) plus relevant ant commands
(schemavalidate)

On Tue, Nov 14, 2017 at 12:11 PM, Nigel Megitt <nigel.megitt@bbc.co.uk>
wrote:

> That would be java and ant itself apparently.
>
> On 14 Nov 2017, at 11:23, Glenn Adams <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>
> 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-r
>> equest-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-c
>> onsensus-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.
>> -----------------------------
>>
>
>
>
> ----------------------------
>
> 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.
>
> ---------------------
>