Re: Protected Policy on Repository Merging Process

Le 14/11/2017 à 11:31, Nigel Megitt a écrit :
> I sent a separate email about addressing the two stage commit - it 
> should not require manual input at all: it is a continuous 
> integration/deployment task that we should be able to automate.
> 
> Just in the same way as David is on the hook for editorial merge changes 
> for WebVTT, I am happy to be on the hook for this for TTML1 and TTML2. I 
> would also ask Thierry to provide backup for this in case I happen to be 
> away or unable to be as responsive as usual.

OK

> 
> Nigel
> 
> 
> ------------------------------------------------------------------------
> *From:* Glenn Adams [glenn@skynav.com]
> *Sent:* 14 November 2017 05:50
> *To:* David Ronca
> *Cc:* Andreas Tai; David Singer; TTWG; Philippe Le Hegaret
> *Subject:* Re: Protected Policy on Repository Merging Process
> 
> 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
>         <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
>         <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 <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.
> 
> ---------------------
>

Received on Tuesday, 14 November 2017 11:38:39 UTC