Hi MarkThis is only for fixing the appeared (very important) problem in the 
community. So, I don't see what will happen to the project in 3 months period 
with RTC process? So, at least 3 months, every commit will be approved by the 
community via consensus. After that, we can safely return back to the normal 
process.

Thanks.Gurkan
On Wednesday, July 5, 2017, 1:15:31 AM GMT+3, Mark Struberg 
<strub...@yahoo.de.INVALID> wrote:

RTC in my experience _only_ works on release branches, but is a total community 
killer on the mainstream branch (master, dev, whatever you call it). 

We usually don't have so many concurrent commits on the same topic. There was 
recently an exceptional case and it got resolved.
Thus -1

Of course discussions might be done first. But not via PR but via mail.
Usually the devs have a good feeling about what is sensible and what not. 
For some deep change one usually sends a patch first for review. That is 
nothing we need to enforce - every good programmer will do just that!
Otoh there are 99.99% of stuff which you just get done and commit it. And if 
there is something fishy, then it get's caught via the commit log mails anyway.

LieGrue,
strub


> Am 03.07.2017 um 10:05 schrieb Jonathan Gallimore 
> <jonathan.gallim...@gmail.com>:
> 
> On Mon, Jul 3, 2017 at 2:04 AM, David Blevins <david.blev...@gmail.com>
> wrote:
> 
>> There’s a discussion on the private list on this topic, but given the
>> recent thread I think it makes sense to move that here.
>> 
>> The vote would be only on this question:
>> 
>>  - Is RTC worth trying for 3 months? (+1,+/-0,-1)
>> 
>> I’ve seen some voices in favor, but do not want to propose a vote
>> without a heads-up.  Specifically, even if many people like the idea
>> we should talk about how we want to do it.
>> 
>> # Review-than-commit
>> 
>> For those that do not know, Review-than-commit is essentially what
>> Github Pull Requests are.  Prior to github, Apache describes them as:
>> 
>> - Commit policy which requires that all changes receive consensus
>>  approval in order to be committed.
>> 
>> I think we’ve seen evidence that:
>> 
>> - Slowing ourselves down can be a good thing.
>> 
>> - Moving ahead after discussion is a good thing.  Discussion should
>>  precede even the first commit.
>> 
>> - More eyes and talk around commits can help documentation efforts.
>> 
>> - As 3 +1s are required, a one-to-one conversation with no one else
>>  included is naturally discouraged.
>> 
>> # Trial basis
>> 
>> My thought is to go RTC for 3 months as a trial.  After 3 months, no
>> action means we revert back to our present CTR.  A new vote would be
>> required to continue RTC in any form, as-was or modified.
>> 
> 
> Unless its obviously unanimous that everyone dislikes RTC at the end of 3
> months, I'd suggest we call a vote to decide how to proceed. Not quite sure
> how that fits into +1/0/-1 however, so may be it should be a 3 month trial,
> followed by 2 weeks for review and discussion (during which we'd still be
> RTC) and then a vote?
> 
> 
>> 
>> The trial-basis is to acknowledge that we are voting on a guess of
>> potential benefits.  This allows us to "try before we buy" and the
>> vote really comes down to if we want to try.  We need not make a
>> decision based on other people's experience and have a means to gain
>> our own experience with a built-in escape clause that triggers lazily.
>> 
>> RTC may sound like a good idea, but our implemention of it may be bad
>> in practise.  It may sound like a bad idea, but we may discover
>> positives we hadn't anticipated.  We don't currently know.
>> 
>> # How would we do it?
>> 
>> Some things that would be good to discuss:
>> 
>>  - How could we use github pull requests?  Other communities do use
>>    them and I suspect there are options we have not explored.
>> 
> 
> I'd be in favour of that, as that process seems to be very well known.
> 
> 
>> 
>>  - Should all reviews be on the dev list? With Github PRs comments
>>    and JIRA comments, there needs to be a source of truth.
>> 
> 
> I think both the discussion and review should happen on the dev list.
> GH/JIRA comments are fine in themselves, but there may be (should be)
> discussion on dev@ before a PR is opened, so having all that discussion in
> one place is important for me. Even if GH comments prove popular, its not
> hard to copy/paste it to dev@ with a link.
> 
> 
>> 
>>  - Should we fully document the process before we try so we can get
>>    the most value from a 3 month trial?
>> 
> 
> I'd be in favour of discussing and documenting.
> 
> 
>> 
>> 
>> --
>> David Blevins
>> http://twitter.com/dblevins
>> http://www.tomitribe.com

Reply via email to