[DISCUSS] Relax RTC for urgent website updates

[Keith Turner <ke...@deenlo.com>]

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.

Re: [DISCUSS] Relax RTC for urgent website updates

[Keith Turner <ke...@deenlo.com>]

On Tue, Aug 8, 2017 at 2:51 PM, Mike Walch <mw...@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 <ct...@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 <ct...@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 <ct...@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.
>> >> >>
>> >>
>> >
>>

Re: [DISCUSS] Relax RTC for urgent website updates

[Mike Walch <mw...@apache.org>]

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.

On Tue, Aug 8, 2017 at 2:48 PM Christopher <ct...@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 <ct...@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 <ct...@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.
> >> >>
> >>
> >
>

Re: [DISCUSS] Relax RTC for urgent website updates

[Christopher <ct...@apache.org>]

(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 <ct...@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 <ct...@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.
>> >>
>>
>

Re: [DISCUSS] Relax RTC for urgent website updates

[Christopher <ct...@apache.org>]

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 <ct...@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.
> >>
>

Re: [DISCUSS] Relax RTC for urgent website updates

[Keith Turner <ke...@deenlo.com>]

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 <ct...@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.
>>

Re: [DISCUSS] Relax RTC for urgent website updates

[Keith Turner <ke...@deenlo.com>]

On Thu, Jul 27, 2017 at 3:04 PM, Christopher <ct...@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

I like this, not specifying any specifics other than a note to a mailing list.

> 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.
>>

Re: [DISCUSS] Relax RTC for urgent website updates

[Christopher <ct...@apache.org>]

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.
>

Re: [DISCUSS] Relax RTC for urgent website updates

[Keith Turner <ke...@deenlo.com>]

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.