;-) On 7 July 2017 at 16:34, Andy Gumbrecht <agumbre...@tomitribe.com> wrote:
> RTC is Consensus Approval and does not need 72h, just 3+1 in any amount > of time. > > On 7 July 2017 at 16:33, Andy Gumbrecht <agumbre...@tomitribe.com> wrote: > >> Those quotes are from Apache. >> >> On 7 July 2017 at 16:30, Romain Manni-Bucau <rmannibu...@gmail.com> >> wrote: >> >>> What Mark meant is if we go through a "vote" then we need to comply to >>> ASF >>> rules. Otherwise anything is up to the project and not a "vote". >>> #semantic >>> ;) >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>> <https://blog-rmannibucau.rhcloud.com> | Old Blog >>> <http://rmannibucau.wordpress.com> | Github < >>> https://github.com/rmannibucau> | >>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory >>> <https://javaeefactory-rmannibucau.rhcloud.com> >>> >>> 2017-07-07 16:28 GMT+02:00 Andy Gumbrecht <agumbre...@tomitribe.com>: >>> >>> > A release is: >>> > >>> > Majority Approval >>> > Refers to a vote (sense 1) which has completed with at least three >>> binding >>> > +1 votes and more +1 votes than -1 votes - You have to wait 72h. >>> > >>> > On 7 July 2017 at 16:25, Andy Gumbrecht <agumbre...@tomitribe.com> >>> wrote: >>> > >>> > > This is not a vote for a release, if you get 3+1s within a minute >>> then >>> > you >>> > > don't have to wait 72h. It is 'Consensus Approval'. >>> > > >>> > > Consensus Approval >>> > > 'Consensus approval' refers to a vote (sense 1) which has *completed >>> > *with >>> > > at least three binding +1 votes and no vetos >>> > > >>> > > On 7 July 2017 at 16:19, Mark Struberg <strub...@yahoo.de.invalid> >>> > wrote: >>> > > >>> > >> You know how voting works at the ASF? ;) >>> > >> >>> > >> Either have a VOTE - with all it's implciations - or not. >>> > >> >>> > >> >>> > >> LieGrue, >>> > >> strub >>> > >> >>> > >> > Am 07.07.2017 um 15:41 schrieb Andy Gumbrecht < >>> > agumbre...@tomitribe.com >>> > >> >: >>> > >> > >>> > >> > There's no 72h waiting period? Just 3+1 to commit. I'd even be >>> for a >>> > >> 2+1. >>> > >> > >>> > >> > As soon as whatever is decided is counted then the commit occurs. >>> That >>> > >> > could be within a few minutes. >>> > >> > >>> > >> > Andy. >>> > >> > >>> > >> > On 7 July 2017 at 14:59, Mark Struberg <strub...@yahoo.de.invalid >>> > >>> > >> wrote: >>> > >> > >>> > >> >> +1 well said, Jeff! >>> > >> >> >>> > >> >> LieGrue, >>> > >> >> strub >>> > >> >> >>> > >> >>> Am 06.07.2017 um 18:37 schrieb Jeff Genender < >>> jgenen...@apache.org >>> > >: >>> > >> >>> >>> > >> >>> Lurking on this, I have to underscore what Mark said. >>> > >> >>> >>> > >> >>> Andy, you are pretty correct on nearly every point that you >>> made. >>> > But >>> > >> >> the things stated are more of refining your current process >>> rather >>> > than >>> > >> >> taking RTC for current committers. You already had RTC with PRs >>> from >>> > >> >> outsiders. If that slipped in, it just means that a trusted >>> > committer >>> > >> >> didn’t do their job. It happens. Breaking a trunk build for a >>> day >>> > >> (or >>> > >> >> even a week) is ok. Thats why its trunk. I cannot tell you how >>> many >>> > >> times >>> > >> >> I have downloaded a project’s trunk and things weren’t quite >>> right. >>> > >> >>> >>> > >> >>> Relative to what prompted this RTC discussion again, I think >>> things >>> > >> got >>> > >> >> emotional and people slipped up afterwards. The beauty of all >>> this >>> > is >>> > >> all >>> > >> >> parties shook hands and made up. Problem was more-or-less >>> solved and >>> > >> the >>> > >> >> project was back on track. >>> > >> >>> >>> > >> >>> IMHO, taking on RTC is punitive. It means that you need to >>> reset >>> > the >>> > >> >> way you do things because you cannot do it yourselves. Do you >>> think >>> > >> you >>> > >> >> are at that point? It didn’t look that way to me… but its >>> certainly >>> > >> >> possible based on what is being done behind the scenes. >>> > >> >>> >>> > >> >>> Just some food for thought. >>> > >> >>> >>> > >> >>> Jeff >>> > >> >>> >>> > >> >>> >>> > >> >>> >>> > >> >>>> On Jul 5, 2017, at 7:49 PM, Andy Gumbrecht < >>> > agumbre...@tomitribe.com >>> > >> > >>> > >> >> wrote: >>> > >> >>>> >>> > >> >>>> The main issue here is that both new and existing developers >>> on the >>> > >> >> project >>> > >> >>>> need breathing space in order to thrive and grow. >>> > >> >>>> >>> > >> >>>> The period between releases is for everyone and not just the >>> few. >>> > It >>> > >> is >>> > >> >>>> only 99.99% OK for one or two individuals. Everyone else seems >>> to >>> > be >>> > >> >>>> suffering behind closed doors or in silence, or fighting >>> constant >>> > >> >> mobbing >>> > >> >>>> to the point where 'our' fun project has become too tedious for >>> > many >>> > >> >>>> people's free time. >>> > >> >>>> >>> > >> >>>> I'm not going to focus on the reasons behind the "Suffocating >>> > >> >> development >>> > >> >>>> environment" thread, only that it was the web 'staging' >>> environment >>> > >> used >>> > >> >>>> for a review, but treated like it was North Korea production >>> > nuclear >>> > >> >> bomb >>> > >> >>>> code. It should have been handled better. We found a >>> resolution the >>> > >> long >>> > >> >>>> way round (github web hosting). >>> > >> >>>> >>> > >> >>>> However, the situation has evolved where existing committers >>> don't >>> > >> >> discuss, >>> > >> >>>> create or assign tickets because they are literally mobbed or >>> > >> hijacked >>> > >> >> by >>> > >> >>>> another committer within minutes. >>> > >> >>>> That is currently so predictable that it has become a kind of >>> > >> un-funny >>> > >> >> joke >>> > >> >>>> even outside of our community. Tickets are often created >>> 'after' a >>> > >> >> commit >>> > >> >>>> with a closed status. >>> > >> >>>> >>> > >> >>>> What needs to change is: >>> > >> >>>> >>> > >> >>>> Committers need to be able to take and work on a ticket in >>> peace >>> > over >>> > >> >>>> several days or even weeks, without being trumped due to >>> impatience >>> > >> or >>> > >> >> the >>> > >> >>>> notion of 'I know better'. >>> > >> >>>> Many can only dedicate a finite amount of time, but still need >>> to >>> > >> push >>> > >> >>>> in-progress work regularly - Git makes that easier now. The >>> review >>> > >> >> process >>> > >> >>>> should be a fun and helpful thing. >>> > >> >>>> >>> > >> >>>> Committers and new contributors should be encouraged to take >>> > tickets. >>> > >> >>>> >>> > >> >>>> At most, impatience should be directed towards discussion, >>> > motivation >>> > >> >> and >>> > >> >>>> encouragement - It's about team play on a global scale, not >>> 'My way >>> > >> or >>> > >> >> the >>> > >> >>>> highway'. >>> > >> >>>> >>> > >> >>>> It is often not viable to test the whole project for a small >>> change >>> > >> - It >>> > >> >>>> takes well over two hours. The buildbot is like our buzzer that >>> > says >>> > >> >> "fix >>> > >> >>>> me" - Not revert me, or trash me, or trump me. >>> > >> >>>> >>> > >> >>>> Note to self: Why does the word 'trump' feel like it's been >>> > hijacked >>> > >> by >>> > >> >>>> someone?... >>> > >> >>>> >>> > >> >>>> The 'buzzer' should be allowed to ring for a day or two, again >>> not >>> > >> >> everyone >>> > >> >>>> stays up the whole night ready to trash a breaking commit. >>> They go >>> > to >>> > >> >>>> sleep, get up, go to work, get home, eat... and then check the >>> > build >>> > >> if >>> > >> >>>> they have time the next day. >>> > >> >>>> >>> > >> >>>> It is OK to break the build. Everyone gets to have a go at >>> that and >>> > >> >> learn >>> > >> >>>> from it. Over and over. We don't release broken builds, only >>> the >>> > good >>> > >> >> ones >>> > >> >>>> in-between. >>> > >> >>>> >>> > >> >>>> Any disagreement at any level goes to a vote. The majority >>> wins. >>> > >> >>>> >>> > >> >>>> I think a trial RTC policy can help achieve these goals as it >>> > forces >>> > >> >>>> community involvement - A good thing. >>> > >> >>>> >>> > >> >>>> Andy. >>> > >> >>>> >>> > >> >>>> >>> > >> >>>> >>> > >> >>>> On 5 July 2017 at 23:02, Jonathan Gallimore < >>> > >> >> jonathan.gallim...@gmail.com> >>> > >> >>>> wrote: >>> > >> >>>> >>> > >> >>>>> Are you referring to the changes in the "Suffocating >>> development >>> > >> >>>>> environment" thread, or something else? In my view, the patch >>> Andy >>> > >> >> applied >>> > >> >>>>> last week had very limited review (1 person), and the revert >>> had >>> > no >>> > >> >> review. >>> > >> >>>>> We've seen contributions come in through GitHub PRs (which is >>> > >> great), >>> > >> >> but >>> > >> >>>>> also applied directly to the repository by committers without >>> > >> further >>> > >> >>>>> discussion (less great), effectively meaning just 1 reviewer >>> - I'm >>> > >> not >>> > >> >> sure >>> > >> >>>>> that's really the spirit of RTC. >>> > >> >>>>> >>> > >> >>>>> Jon >>> > >> >>>>> >>> > >> >>>>> >>> > >> >>>>> On Wed, Jul 5, 2017 at 6:06 PM, Mark Struberg >>> > >> >> <strub...@yahoo.de.invalid> >>> > >> >>>>> wrote: >>> > >> >>>>> >>> > >> >>>>>> As far as I recall the original issue was initially caused by >>> > >> >> applying a >>> > >> >>>>>> PR. >>> > >> >>>>>> That means we had this very issue with a commit which had >>> RTC in >>> > >> >> place. >>> > >> >>>>>> >>> > >> >>>>>> Draw your own conclusions... >>> > >> >>>>>> >>> > >> >>>>>> LieGrue, >>> > >> >>>>>> strub >>> > >> >>>>>> >>> > >> >>>>>> >>> > >> >>>>>>> Am 05.07.2017 um 14:26 schrieb Romain Manni-Bucau < >>> > >> >>>>> rmannibu...@gmail.com >>> > >> >>>>>>> : >>> > >> >>>>>>> >>> > >> >>>>>>> Hmm, let put it in a raw way: can we skip the asf list on >>> these >>> > >> >>>>>>> discussions? Literally means can be use the way everybody >>> uses >>> > for >>> > >> >> RTC, >>> > >> >>>>>> ie >>> > >> >>>>>>> github PRs *only*. If not I don't see the point to use it >>> since >>> > >> >>>>>>> contributors we got are mainly github/jira and I think it is >>> > >> natural >>> > >> >>>>> as a >>> > >> >>>>>>> contributor to use these media instead of the list. >>> > >> >>>>>>> >>> > >> >>>>>>> Can we somehow merge the github flow with the mailing in a >>> > >> smoother >>> > >> >> way >>> > >> >>>>>>> than the jira integration - and even make jira optional? If >>> not >>> > >> I'm >>> > >> >>>>>> pretty >>> > >> >>>>>>> sure it doesn't need any more evaluation, if we can then it >>> can >>> > be >>> > >> >>>>> great >>> > >> >>>>>> to >>> > >> >>>>>>> benefit from github well known flow. >>> > >> >>>>>>> >>> > >> >>>>>>> To rephrase it to maybe make it even more explicit: it is >>> not >>> > >> about >>> > >> >>>>>> making >>> > >> >>>>>>> our - as committers - work easier but making contributions >>> > easier. >>> > >> >>>>>>> >>> > >> >>>>>>> >>> > >> >>>>>>> Romain Manni-Bucau >>> > >> >>>>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>> > >> >>>>>>> <https://blog-rmannibucau.rhcloud.com> | Old Blog >>> > >> >>>>>>> <http://rmannibucau.wordpress.com> | Github < >>> > >> >>>>>> https://github.com/rmannibucau> | >>> > >> >>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE >>> > >> Factory >>> > >> >>>>>>> <https://javaeefactory-rmannibucau.rhcloud.com> >>> > >> >>>>>>> >>> > >> >>>>>>> 2017-07-05 13:23 GMT+02:00 Jonathan Gallimore < >>> > >> >>>>>> jonathan.gallim...@gmail.com> >>> > >> >>>>>>> : >>> > >> >>>>>>> >>> > >> >>>>>>>> As I see it, while the recent issue with the documentation >>> was >>> > >> >>>>> probably >>> > >> >>>>>> the >>> > >> >>>>>>>> trigger for discussing RTC on dev@, I think the general >>> idea >>> > is >>> > >> >>>>>> actually >>> > >> >>>>>>>> to >>> > >> >>>>>>>> get more discussion going on around features and fixes, >>> and to >>> > >> >>>>> encourage >>> > >> >>>>>>>> more interaction in the review process. We are struggling >>> as a >>> > >> >>>>>> community in >>> > >> >>>>>>>> that regard. The documentation issue might now be "fixed" >>> by >>> > >> using >>> > >> >>>>>> personal >>> > >> >>>>>>>> html area usage, but I still think RTC is worthy of >>> > >> consideration. >>> > >> >> We >>> > >> >>>>>> are >>> > >> >>>>>>>> seeing some contributions come in from new contributors >>> and we >>> > >> have >>> > >> >> an >>> > >> >>>>>>>> opportunity to nurture them through this discussion and >>> review >>> > >> >>>>> process. >>> > >> >>>>>>>> >>> > >> >>>>>>>> Incidentally, if we trialled RTC and saw improvements, I'd >>> vote >>> > >> to >>> > >> >>>>> keep >>> > >> >>>>>> it >>> > >> >>>>>>>> after 3 months and not "safely return back". If we don't >>> see >>> > >> >>>>>> improvements, >>> > >> >>>>>>>> I'd be trying to think of some other ideas to try. I think >>> we'd >>> > >> all >>> > >> >> be >>> > >> >>>>>> open >>> > >> >>>>>>>> to other suggestions as well, but I'm of the view that if >>> we >>> > >> don't >>> > >> >> try >>> > >> >>>>>>>> something, then potentially nothing will change. >>> > >> >>>>>>>> >>> > >> >>>>>>>> Jon >>> > >> >>>>>>>> >>> > >> >>>>>>>> On Wed, Jul 5, 2017 at 9:25 AM, Romain Manni-Bucau < >>> > >> >>>>>> rmannibu...@gmail.com> >>> > >> >>>>>>>> wrote: >>> > >> >>>>>>>> >>> > >> >>>>>>>>> 2017-07-05 10:00 GMT+02:00 Gurkan Erdogdu < >>> > >> gurkanerdo...@yahoo.com >>> > >> >> . >>> > >> >>>>>>>>> invalid>: >>> > >> >>>>>>>>> >>> > >> >>>>>>>>>> Romain>>>>@Gurkan: concretely nothing changed factually >>> since >>> > >> we >>> > >> >>>>>>>>> discussed >>> > >> >>>>>>>>>> it and concluded we can't pay the overhead at the moment >>> so >>> > why >>> > >> >>>>>> pushing >>> > >> >>>>>>>>>> it?I looked at the commit history from github ( >>> > >> >>>>>>>>> https://github.com/apache/ >>> > >> >>>>>>>>>> tomee/graphs/contributors). Only some couple of members >>> > provide >>> > >> >>>>>>>>>> contributions in last couple of years. We need a more >>> > >> >> stable/healthy >>> > >> >>>>>>>>>> community to increase the chance of long living the >>> project. >>> > >> You >>> > >> >> are >>> > >> >>>>>>>>> wrong, >>> > >> >>>>>>>>>> the reason behind the such discussion is not related with >>> > prod, >>> > >> >>>>>> website >>> > >> >>>>>>>>> or >>> > >> >>>>>>>>>> project source code. We are looking for some alternative >>> > >> solution >>> > >> >>>>> (at >>> > >> >>>>>>>>> least >>> > >> >>>>>>>>>> temporarily) because of the mentioned problems. I suspect >>> > that >>> > >> >> this >>> > >> >>>>>>>> type >>> > >> >>>>>>>>> of >>> > >> >>>>>>>>>> conflicts may occur in the future again. I am pushing >>> this >>> > for >>> > >> the >>> > >> >>>>>>>>> success >>> > >> >>>>>>>>>> and future of Apache TomEE. I am not a PMC member or >>> > committer >>> > >> of >>> > >> >>>>>> TomEE >>> > >> >>>>>>>>>> project, but I just wanted to give my comments as ASF >>> member. >>> > >> >>>>>>>>>> >>> > >> >>>>>>>>> >>> > >> >>>>>>>>> Don't think so Gurkan, the problem was really bound to end >>> > user >>> > >> >>>>> direct >>> > >> >>>>>>>>> impact and we tackled it with the personal html area >>> usage we >>> > >> need >>> > >> >> to >>> > >> >>>>>>>>> document now. >>> > >> >>>>>>>>> >>> > >> >>>>>>>>> >>> > >> >>>>>>>>>> Regards.Gurkan- >>> > >> >>>>>>>>>> >>> > >> >>>>>>>>>> >>> > >> >>>>>>>>>> >>> > >> >>>>>>>>>> >>> > >> >>>>>>>>>> >>> > >> >>>>>>>>>> On Wednesday, July 5, 2017, 10:13:22 AM GMT+3, Romain >>> > >> Manni-Bucau >>> > >> >> < >>> > >> >>>>>>>>>> rmannibu...@gmail.com> wrote: >>> > >> >>>>>>>>>> >>> > >> >>>>>>>>>> @Gurkan: concretely nothing changed factually since we >>> > >> discussed >>> > >> >> it >>> > >> >>>>>> and >>> > >> >>>>>>>>>> concluded we can't pay the overhead at the moment so why >>> > >> pushing >>> > >> >> it? >>> > >> >>>>>>>>>> Concretely the issue was very particular in term of >>> process >>> > >> cause >>> > >> >>>>>>>>> affecting >>> > >> >>>>>>>>>> almost directly our "prod" versus our project source >>> doesn't >>> > >> and >>> > >> >> we >>> > >> >>>>>> can >>> > >> >>>>>>>>>> therefore tolerate more latency. And side note (probably >>> some >>> > >> >>>>> wording >>> > >> >>>>>>>>> issue >>> > >> >>>>>>>>>> but just to make it obvious if not): if it is to go back >>> to >>> > the >>> > >> >>>>> normal >>> > >> >>>>>>>>>> process anyway after then we can gain these 3 months and >>> > >> already >>> > >> >>>>> work >>> > >> >>>>>>>> as >>> > >> >>>>>>>>> we >>> > >> >>>>>>>>>> and we'll do ;). >>> > >> >>>>>>>>>> >>> > >> >>>>>>>>>> >>> > >> >>>>>>>>>> Romain Manni-Bucau >>> > >> >>>>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>> > >> >>>>>>>>>> <https://blog-rmannibucau.rhcloud.com> | Old Blog >>> > >> >>>>>>>>>> <http://rmannibucau.wordpress.com> | Github < >>> > >> https://github.com/ >>> > >> >>>>>>>>>> rmannibucau> | >>> > >> >>>>>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | >>> JavaEE >>> > >> >> Factory >>> > >> >>>>>>>>>> <https://javaeefactory-rmannibucau.rhcloud.com> >>> > >> >>>>>>>>>> >>> > >> >>>>>>>>>> 2017-07-05 7:28 GMT+02:00 Gurkan Erdogdu < >>> > >> gurkanerdo...@yahoo.com >>> > >> >> . >>> > >> >>>>>>>>>> invalid>: >>> > >> >>>>>>>>>> >>> > >> >>>>>>>>>>> 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 >>> > >> >>>>>>>>>>> >>> > >> >>>>>>>>>> >>> > >> >>>>>>>>> >>> > >> >>>>>>>> >>> > >> >>>>>> >>> > >> >>>>>> >>> > >> >>>>> >>> > >> >>>> >>> > >> >>>> >>> > >> >>>> >>> > >> >>>> -- >>> > >> >>>> Andy Gumbrecht >>> > >> >>>> https://twitter.com/AndyGeeDe >>> > >> >>>> http://www.tomitribe.com >>> > >> >>> >>> > >> >> >>> > >> >> >>> > >> > >>> > >> > >>> > >> > -- >>> > >> > Andy Gumbrecht >>> > >> > https://twitter.com/AndyGeeDe >>> > >> > http://www.tomitribe.com >>> > >> >>> > >> >>> > > >>> > > >>> > > -- >>> > > Andy Gumbrecht >>> > > https://twitter.com/AndyGeeDe >>> > > http://www.tomitribe.com >>> > > >>> > >>> > >>> > >>> > -- >>> > Andy Gumbrecht >>> > https://twitter.com/AndyGeeDe >>> > http://www.tomitribe.com >>> > >>> >> >> >> >> -- >> Andy Gumbrecht >> https://twitter.com/AndyGeeDe >> http://www.tomitribe.com >> > > > > -- > Andy Gumbrecht > https://twitter.com/AndyGeeDe > http://www.tomitribe.com > -- Andy Gumbrecht https://twitter.com/AndyGeeDe http://www.tomitribe.com
