You know how voting works at the ASF? ;) Either have a VOTE - with all it's implciations - or not.
LieGrue, strub > Am 07.07.2017 um 15:41 schrieb Andy Gumbrecht <agumbre...@tomitribe.com>: > > 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
