On Tue, Aug 8, 2017 at 2:51 PM, Mike Walch <mwa...@apache.org> wrote:
> A pull request to the website makes sense to me as that is where the policy
> change to RTC will be communicated to new contributors.  If anyone has
> objections to the change, they can -1 the pull request.

SGTM

>
> On Tue, Aug 8, 2017 at 2:48 PM Christopher <ctubb...@apache.org> wrote:
>
>> (by "update the website", I mean, just do a PR against the website for
>> formal review)
>>
>> On Tue, Aug 8, 2017 at 2:36 PM Christopher <ctubb...@apache.org> wrote:
>>
>> > Do we even need to vote? I think we already have consensus. Can probably
>> > just update the website at this point.
>> >
>> > On Tue, Aug 8, 2017 at 2:01 PM Keith Turner <ke...@deenlo.com> wrote:
>> >
>> >> Any thoughts about the following vote email?
>> >>
>> >> Subject : [VOTE] Allow bypassing RTC for urgent changes
>> >>
>> >> All changes to Fluo are currently made via review then commit (RTC).
>> >> Please
>> >> vote on allowing bypassing RTC for urgent updates with the following
>> >> commit
>> >> process.
>> >>
>> >>  * Make an appropriate level of effort to request a review.
>> >>  * If applicable,  take appropriate steps to ensure that their actions
>> >> can be
>> >>    reversed.
>> >>  * Send an explanation to the dev list (or private list, if sensitive)
>> >>    immediately after committing justifying the urgency.
>> >>
>> >> Such emergencies should be extremely rare, and would typically only
>> apply
>> >> to
>> >> things not blocked by a release vote (such as a website change).
>> >>
>> >> This vote is open for 3 days.
>> >>
>> >> On Thu, Jul 27, 2017 at 3:04 PM, Christopher <ctubb...@apache.org>
>> wrote:
>> >> > How about something like:
>> >> >
>> >> > """
>> >> > Reviews may only be bypassed in the case of an emergency, and only
>> >> after an
>> >> > appropriate level of effort has been made to request a review. Before
>> >> > bypassing a review, the committer should take appropriate steps to
>> >> ensure
>> >> > that their actions can be reversed, if necessary. The committer should
>> >> also
>> >> > send an explanation to the dev list (or private list, if sensitive)
>> >> > immediately afterwards justifying the urgency. The PMC members will
>> >> decide
>> >> > whether the action was warranted, and what follow-on actions should be
>> >> > taken, if any. Such emergencies should be extremely rare, and would
>> >> > typically only apply to things not blocked by a release vote (such as
>> a
>> >> > website change).
>> >> > """
>> >> >
>> >> > The above proposed wording has the benefit of being simple, flexible,
>> >> and
>> >> > accountable, but not being tied to any complex rules like tagging,
>> >> > labeling, waiting for specific durations, etc. that can undermine the
>> >> > efficacy of an emergency action. It's also very broad, so it isn't
>> >> > dependent on specific workflows or infrastructure tools, which can
>> >> change
>> >> > over time.
>> >> >
>> >> > On Thu, Jul 27, 2017 at 11:12 AM Keith Turner <ke...@deenlo.com>
>> wrote:
>> >> >
>> >> >> In addition to tagging as urgent, a short explanation of why its
>> >> >> urgent should be given.
>> >> >>
>> >> >> On Thu, Jul 27, 2017 at 11:10 AM, Keith Turner <ke...@deenlo.com>
>> >> wrote:
>> >> >> > I have been thinking that it may be useful to relax RTC for urgent
>> >> >> > website updates.   I can not imagine this being needed for Fluo or
>> >> >> > Fluo Recipes because of the 3 day release process.  However, the
>> >> >> > website is always immediately available after any update.  It would
>> >> be
>> >> >> > nice to have an agreed on mechanism for bypassing RTC for the
>> >> website.
>> >> >> > Possibly something like the following :
>> >> >> >
>> >> >> >  * Create PR for website and tag it urgent
>> >> >> >  * Attempt to contact other PMC members
>> >> >> >  * Wait X time (for example 10 mins)
>> >> >> >  * After X time if no one has indicated they are reviewing, then
>> >> >> > commiter can push
>> >> >> >
>> >> >> > I think the policy should include something like : should this
>> policy
>> >> >> > ever cause strife in the community, it must be repealed
>> immediately.
>> >> >>
>> >>
>> >
>>

Reply via email to