At the end of the day it is up to everyone on a project to decide on what form RTC would be managed and applied if we chose to adopt it. It's open to interpretation through the set of guidelines.
Interpreting a rigid and unworkable set of rules based on those guidelines would make it impossible to follow. Applying the guidelines from the perspective of a Pull Request peer review does not make it impossible. Andy. On 8 July 2017 at 09:59, Andy Gumbrecht <agumbre...@tomitribe.com> wrote: > 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 > -- Andy Gumbrecht https://twitter.com/AndyGeeDe http://www.tomitribe.com
