There's no 72h waiting period? Just 3+1 to commit. I'd even be for a 2+1. As soon as whatever is decided is counted then the commit occurs. That could be within a few minutes.
Andy. On 7 July 2017 at 14:59, Mark Struberg <strub...@yahoo.de.invalid> wrote: > +1 well said, Jeff! > > LieGrue, > strub > > > Am 06.07.2017 um 18:37 schrieb Jeff Genender <jgenen...@apache.org>: > > > > Lurking on this, I have to underscore what Mark said. > > > > Andy, you are pretty correct on nearly every point that you made. But > the things stated are more of refining your current process rather than > taking RTC for current committers. You already had RTC with PRs from > outsiders. If that slipped in, it just means that a trusted committer > didn’t do their job. It happens. Breaking a trunk build for a day (or > even a week) is ok. Thats why its trunk. I cannot tell you how many times > I have downloaded a project’s trunk and things weren’t quite right. > > > > Relative to what prompted this RTC discussion again, I think things got > emotional and people slipped up afterwards. The beauty of all this is all > parties shook hands and made up. Problem was more-or-less solved and the > project was back on track. > > > > IMHO, taking on RTC is punitive. It means that you need to reset the > way you do things because you cannot do it yourselves. Do you think you > are at that point? It didn’t look that way to me… but its certainly > possible based on what is being done behind the scenes. > > > > Just some food for thought. > > > > Jeff > > > > > > > >> On Jul 5, 2017, at 7:49 PM, Andy Gumbrecht <agumbre...@tomitribe.com> > wrote: > >> > >> The main issue here is that both new and existing developers on the > project > >> need breathing space in order to thrive and grow. > >> > >> The period between releases is for everyone and not just the few. It is > >> only 99.99% OK for one or two individuals. Everyone else seems to be > >> suffering behind closed doors or in silence, or fighting constant > mobbing > >> to the point where 'our' fun project has become too tedious for many > >> people's free time. > >> > >> I'm not going to focus on the reasons behind the "Suffocating > development > >> environment" thread, only that it was the web 'staging' environment used > >> for a review, but treated like it was North Korea production nuclear > bomb > >> code. It should have been handled better. We found a resolution the long > >> way round (github web hosting). > >> > >> However, the situation has evolved where existing committers don't > discuss, > >> create or assign tickets because they are literally mobbed or hijacked > by > >> another committer within minutes. > >> That is currently so predictable that it has become a kind of un-funny > joke > >> even outside of our community. Tickets are often created 'after' a > commit > >> with a closed status. > >> > >> What needs to change is: > >> > >> Committers need to be able to take and work on a ticket in peace over > >> several days or even weeks, without being trumped due to impatience or > the > >> notion of 'I know better'. > >> Many can only dedicate a finite amount of time, but still need to push > >> in-progress work regularly - Git makes that easier now. The review > process > >> should be a fun and helpful thing. > >> > >> Committers and new contributors should be encouraged to take tickets. > >> > >> At most, impatience should be directed towards discussion, motivation > and > >> encouragement - It's about team play on a global scale, not 'My way or > the > >> highway'. > >> > >> It is often not viable to test the whole project for a small change - It > >> takes well over two hours. The buildbot is like our buzzer that says > "fix > >> me" - Not revert me, or trash me, or trump me. > >> > >> Note to self: Why does the word 'trump' feel like it's been hijacked by > >> someone?... > >> > >> The 'buzzer' should be allowed to ring for a day or two, again not > everyone > >> stays up the whole night ready to trash a breaking commit. They go to > >> sleep, get up, go to work, get home, eat... and then check the build if > >> they have time the next day. > >> > >> It is OK to break the build. Everyone gets to have a go at that and > learn > >> from it. Over and over. We don't release broken builds, only the good > ones > >> in-between. > >> > >> Any disagreement at any level goes to a vote. The majority wins. > >> > >> I think a trial RTC policy can help achieve these goals as it forces > >> community involvement - A good thing. > >> > >> Andy. > >> > >> > >> > >> On 5 July 2017 at 23:02, Jonathan Gallimore < > jonathan.gallim...@gmail.com> > >> wrote: > >> > >>> 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 > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>> > >>>> > >>> > >> > >> > >> > >> -- > >> Andy Gumbrecht > >> https://twitter.com/AndyGeeDe > >> http://www.tomitribe.com > > > > -- Andy Gumbrecht https://twitter.com/AndyGeeDe http://www.tomitribe.com
