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
