- From: Pierre-Anthony Lemieux <pal@sandflow.com>
- Date: Mon, 13 Nov 2017 22:56:28 -0800
- To: Glenn Adams <glenn@skynav.com>
- Cc: David Ronca <dronca@netflix.com>, Andreas Tai <tai@irt.de>, David Singer <singer@mac.com>, TTWG <public-tt@w3.org>, Philippe Le Hegaret <plh@w3.org>
> 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