Vote <https://www.apache.org/foundation/glossary.html#Vote>1. The process of making a formal decision. ('The vote for foo will close in three days.') 2. The expression of a positive or negative opinion, or a veto, as part of a formal decision. ('My vote is -1 because foo smells bad.') The brackets denote 'implied', not a rule.
On 8 July 2017 at 09:37, agumbre...@tomitribe.com <agumbre...@tomitribe.com> wrote: > You are apply the majority vote to a consensus vote. > > agumbre...@tomitribe.com > http://www.tomitribe.com > > Sent from my mobile device. > > ----- Reply message ----- > From: "Mark Struberg" <strub...@yahoo.de.INVALID> > To: <dev@tomee.apache.org> > Subject: [Discuss] Review-than-commit 3 month trial > Date: Sat, Jul 8, 2017 09:23 > > Andy, please read the documentation! > > The definition of 'RTC' > https://www.apache.org/foundation/glossary.html#ReviewThenCommit > > points to 'Consensus > Approval'https://www.apache.org/foundation/glossary.html#ConsensusApproval > > Which in turn points to > 'Vote'https://www.apache.org/foundation/glossary.html#Vote > > which of course has a time parameter. > It defaults to 3 days, but of course can be defined different. Otoh a period > of below 1 day contradicts the ASF around-the-globe policy. > > Btw, RTC also implies that everyone who voted also did fully test the > patch!https://www.apache.org/foundation/voting.html > > That means that everyone who votes will run the full 30 minutes build for > each and every commit candidate. > Now tell me when you did run ALL tests locally the last time? > > Sadly I was not able to run all the tests locally in one go. Not on my > MacBook, nor on my Linux Workstation. > I already reported this quite a few times and we finally need to improve this. > Once we make our test suite reliably working again and bring committers to > run it before they commit, then we might also not need such a review anymore. > > LieGrue, > strub > > > > Am 08.07.2017 um 00:51 schrieb Andy Gumbrecht <agumbre...@tomitribe.com>: > > > > That's *not* how a consensus vote works. An RTC commit does not need a > > majority at all - That would be a 'Majority Approval', and of course *that* > > is not any use at all for RTC. > > > > No one here is suggesting it that way, and it would be stupid to make > > anyone wait 72h for a simple review. It is not stupid to say create a PR > > and have someone else review it - That's the workflow on just about every > > community git project out there - Don't merge your own PR is a really > > common process. > > > > If David comes on 9 hrs later and doesn't like it then he'd need to submit > > a counter PR, and that would also need 3+1. That's the whole point. > > > > It's about teamwork and eyes on by more than just one person, not about > > making it impossible to work. If you do a PR and JL *and* Romain ack it > > then where is the issue with that? > > > > You're seeing it, or making it sound, way more complicated than it is. > > Right now there is *no* consensus. Right now anyone can commit at any time > > without eyes on by anyone else. Right now if David doesn't like it 9 hours > > later, then he can just *trash* it as he sees fit. > > > > So, a 3+1 commit with no time frame makes a lot of sense imo. It's little > > more than a PR with peer review. > > > > Andy. > > > > On 8 July 2017 at 00:17, Mark Struberg <strub...@yahoo.de.invalid> wrote: > > > >> Just for sake of clarifying the procedural stuff. A consensus vote > >> requires that the majority of PMC members did vote. > >> Consider I commit something and ping lt's say JL and Romain via IRC to ack > >> it. They send their +1 in the frame 1 minute after my PR. Then I go on and > >> push it. Now 9 hours later David awakes over in US and he doesn't like it. > >> He might vote -1, but it's already committed. Not what's intended, isn't? > >> > >> A VOTE without any time frame or a quorum does make little sense imo. > >> > >> LieGrue, > >> strub > >> > >>> Am 07.07.2017 um 16:25 schrieb Andy Gumbrecht <agumbre...@tomitribe.com > >>> : > >>> > >>> 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
