If someone comes up 'after' the Consensus Approval (3+1) with a -1 then they must submit a counter PR, that must also pass the RTC.
It's pretty straight forward. On 7 July 2017 at 16:36, Andy Gumbrecht <agumbre...@tomitribe.com> wrote: > ;-) > > 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 > -- Andy Gumbrecht https://twitter.com/AndyGeeDe http://www.tomitribe.com
