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