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 >>>>> >>>> >>> >>
