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