I brought up RTC a few months ago as a way to get more dev list discussion, more people aware of the code going in and higher participation overall. The commit/revert ping-pong we had last week seemed to revive the topic.
I haven’t seen us properly applying RTC, which requires 3 +1s and no -1s. -- David Blevins http://twitter.com/dblevins http://www.tomitribe.com > On Jul 5, 2017, at 10:06 AM, 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 >>>>>> >>>>> >>>> >>> >
