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