No, I was referring to the discussion a few months back when RTC also got praised as THE solution for all sorts of community problems. Back then it was caused by a PR even, so a review *was* in place.
Think about the following; If we really require 3+1 and 72h voting period for EACH commit, then would this really make contributing _easier_? Seriously... LieGrue, strub > Am 05.07.2017 um 23:02 schrieb Jonathan Gallimore > <jonathan.gallim...@gmail.com>: > > 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 >>>>>>> >>>>>> >>>>> >>>> >> >>
