Not sure there will be a consensus so how do we close that thread? >From what happent last weeks seems project is back on track so I'm tempted to say we should keep it like that for now. Alternative is to do an ASF vote to see if we go with RTC.
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-07 16:19 GMT+02:00 Mark Struberg <strub...@yahoo.de.invalid>: > 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 > >
