You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by David Blevins <da...@gmail.com> on 2017/07/03 01:04:41 UTC
[Discuss] Review-than-commit 3 month trial
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.
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.
- Should all reviews be on the dev list? With Github PRs comments
and JIRA comments, there needs to be a source of truth.
- Should we fully document the process before we try so we can get
the most value from a 3 month trial?
--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
Re: [Discuss] Review-than-commit 3 month trial
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
No, I was referring to the discussion a few months back when RTC also got praised as THE solution for all sorts of community problems. Back then it was caused by a PR even, so a review *was* in place.
Think about the following;
If we really require 3+1 and 72h voting period for EACH commit, then would this really make contributing _easier_? Seriously...
LieGrue,
strub
> Am 05.07.2017 um 23:02 schrieb Jonathan Gallimore <jo...@gmail.com>:
>
> 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 <st...@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 <rmannibucau@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.gallimore@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 <
>> rmannibucau@gmail.com>
>>>> wrote:
>>>>
>>>>> 2017-07-05 10:00 GMT+02:00 Gurkan Erdogdu <gurkanerdogdu@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 <
>>>>>> rmannibucau@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 <gurkanerdogdu@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
>>>>>>> <st...@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.gallimore@gmail.com>:
>>>>>>>>
>>>>>>>> On Mon, Jul 3, 2017 at 2:04 AM, David Blevins <
>>>>> david.blevins@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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>>
Re: [Discuss] Review-than-commit 3 month trial
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <st...@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 <agumbrecht@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 <st...@yahoo.de.invalid>
> wrote:
> >
> >> +1 well said, Jeff!
> >>
> >> LieGrue,
> >> strub
> >>
> >>> Am 06.07.2017 um 18:37 schrieb Jeff Genender <jg...@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 <ag...@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.gallimore@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
> >> <st...@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 <
> >>>>> rmannibucau@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.gallimore@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 <
> >>>>>> rmannibucau@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> 2017-07-05 10:00 GMT+02:00 Gurkan Erdogdu <
> gurkanerdogdu@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
> >> <
> >>>>>>>>>> rmannibucau@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 <
> gurkanerdogdu@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
> >>>>>>>>>>> <st...@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.gallimore@gmail.com>:
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Mon, Jul 3, 2017 at 2:04 AM, David Blevins <
> >>>>>>>>> david.blevins@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
>
>
Re: [Discuss] Review-than-commit 3 month trial
Posted by David Blevins <da...@gmail.com>.
Just so we don’t spin on this, I can confirm the Board does allow us to make our own commit rules with the exception that a -1 in any model is a veto and cannot be overridden.
The “must test” requirement was relaxed on Geronimo midway through the mandated RTC because we had a CI system. When the PMC Chair gave the project the right to chose the commit model, several revised RTC models were discussed and considered. There were a handful of Board members in that discussion helping it along.
Of course anything we chose will be in the board report and reviewed, so we’re safe and should feel encouraged to forge our own way. They’ll bump us in the right direction if we need it. It takes quite a lot to make the board actually upset. Making mistakes or having problems doesn’t do it. They only start to get upset when the mistakes and problems go on too long and the project refuses to acknowledge them or do anything about it.
We should feel encouraged to dream up awesome ways we can succeed.
--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
> On Jul 8, 2017, at 12:23 AM, Mark Struberg <st...@yahoo.de.INVALID> wrote:
>
> Andy, please read the documentation!
>
> The definition of 'RTC'
> https://www.apache.org/foundation/glossary.html#ReviewThenCommit
>
> points to 'Consensus Approval'
> https://www.apache.org/foundation/glossary.html#ConsensusApproval
>
> Which in turn points to 'Vote'
> https://www.apache.org/foundation/glossary.html#Vote
>
> which of course has a time parameter.
> It defaults to 3 days, but of course can be defined different. Otoh a period of below 1 day contradicts the ASF around-the-globe policy.
>
> Btw, RTC also implies that everyone who voted also did fully test the patch!
> https://www.apache.org/foundation/voting.html
>
> That means that everyone who votes will run the full 30 minutes build for each and every commit candidate.
> Now tell me when you did run ALL tests locally the last time?
>
> Sadly I was not able to run all the tests locally in one go. Not on my MacBook, nor on my Linux Workstation.
> I already reported this quite a few times and we finally need to improve this.
> Once we make our test suite reliably working again and bring committers to run it before they commit, then we might also not need such a review anymore.
>
> LieGrue,
> strub
>
>
>> Am 08.07.2017 um 00:51 schrieb Andy Gumbrecht <ag...@tomitribe.com>:
>>
>> That's *not* how a consensus vote works. An RTC commit does not need a
>> majority at all - That would be a 'Majority Approval', and of course *that*
>> is not any use at all for RTC.
>>
>> No one here is suggesting it that way, and it would be stupid to make
>> anyone wait 72h for a simple review. It is not stupid to say create a PR
>> and have someone else review it - That's the workflow on just about every
>> community git project out there - Don't merge your own PR is a really
>> common process.
>>
>> If David comes on 9 hrs later and doesn't like it then he'd need to submit
>> a counter PR, and that would also need 3+1. That's the whole point.
>>
>> It's about teamwork and eyes on by more than just one person, not about
>> making it impossible to work. If you do a PR and JL *and* Romain ack it
>> then where is the issue with that?
>>
>> You're seeing it, or making it sound, way more complicated than it is.
>> Right now there is *no* consensus. Right now anyone can commit at any time
>> without eyes on by anyone else. Right now if David doesn't like it 9 hours
>> later, then he can just *trash* it as he sees fit.
>>
>> So, a 3+1 commit with no time frame makes a lot of sense imo. It's little
>> more than a PR with peer review.
>>
>> Andy.
>>
>> On 8 July 2017 at 00:17, Mark Struberg <st...@yahoo.de.invalid> wrote:
>>
>>> Just for sake of clarifying the procedural stuff. A consensus vote
>>> requires that the majority of PMC members did vote.
>>> Consider I commit something and ping lt's say JL and Romain via IRC to ack
>>> it. They send their +1 in the frame 1 minute after my PR. Then I go on and
>>> push it. Now 9 hours later David awakes over in US and he doesn't like it.
>>> He might vote -1, but it's already committed. Not what's intended, isn't?
>>>
>>> A VOTE without any time frame or a quorum does make little sense imo.
>>>
>>> LieGrue,
>>> strub
>>>
>>>> Am 07.07.2017 um 16:25 schrieb Andy Gumbrecht <agumbrecht@tomitribe.com
>>>> :
>>>>
>>>> This is not a vote for a release, if you get 3+1s within a minute then
>>> you
>>>> don't have to wait 72h. It is 'Consensus Approval'.
>>>>
>>>> Consensus Approval
>>>> 'Consensus approval' refers to a vote (sense 1) which has *completed
>>> *with
>>>> at least three binding +1 votes and no vetos
>>>>
>>>> On 7 July 2017 at 16:19, Mark Struberg <st...@yahoo.de.invalid>
>>> wrote:
>>>>
>>>>> 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 <
>>> agumbrecht@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 <st...@yahoo.de.invalid>
>>>>> wrote:
>>>>>>
>>>>>>> +1 well said, Jeff!
>>>>>>>
>>>>>>> LieGrue,
>>>>>>> strub
>>>>>>>
>>>>>>>> Am 06.07.2017 um 18:37 schrieb Jeff Genender <jg...@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 <
>>> agumbrecht@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.gallimore@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
>>>>>>> <st...@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 <
>>>>>>>>>> rmannibucau@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.gallimore@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 <
>>>>>>>>>>> rmannibucau@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2017-07-05 10:00 GMT+02:00 Gurkan Erdogdu <
>>>>> gurkanerdogdu@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
>>>>>>> <
>>>>>>>>>>>>>>> rmannibucau@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 <
>>>>> gurkanerdogdu@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
>>>>>>>>>>>>>>>> <st...@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.gallimore@gmail.com>:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Mon, Jul 3, 2017 at 2:04 AM, David Blevins <
>>>>>>>>>>>>>> david.blevins@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
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Andy Gumbrecht
>>>> https://twitter.com/AndyGeeDe
>>>> http://www.tomitribe.com
>>>
>>>
>>
>>
>> --
>> Andy Gumbrecht
>> https://twitter.com/AndyGeeDe
>> http://www.tomitribe.com
>
Re: [Discuss] Review-than-commit 3 month trial
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
Andy, please read the documentation!
The definition of 'RTC'
https://www.apache.org/foundation/glossary.html#ReviewThenCommit
points to 'Consensus Approval'
https://www.apache.org/foundation/glossary.html#ConsensusApproval
Which in turn points to 'Vote'
https://www.apache.org/foundation/glossary.html#Vote
which of course has a time parameter.
It defaults to 3 days, but of course can be defined different. Otoh a period of below 1 day contradicts the ASF around-the-globe policy.
Btw, RTC also implies that everyone who voted also did fully test the patch!
https://www.apache.org/foundation/voting.html
That means that everyone who votes will run the full 30 minutes build for each and every commit candidate.
Now tell me when you did run ALL tests locally the last time?
Sadly I was not able to run all the tests locally in one go. Not on my MacBook, nor on my Linux Workstation.
I already reported this quite a few times and we finally need to improve this.
Once we make our test suite reliably working again and bring committers to run it before they commit, then we might also not need such a review anymore.
LieGrue,
strub
> Am 08.07.2017 um 00:51 schrieb Andy Gumbrecht <ag...@tomitribe.com>:
>
> That's *not* how a consensus vote works. An RTC commit does not need a
> majority at all - That would be a 'Majority Approval', and of course *that*
> is not any use at all for RTC.
>
> No one here is suggesting it that way, and it would be stupid to make
> anyone wait 72h for a simple review. It is not stupid to say create a PR
> and have someone else review it - That's the workflow on just about every
> community git project out there - Don't merge your own PR is a really
> common process.
>
> If David comes on 9 hrs later and doesn't like it then he'd need to submit
> a counter PR, and that would also need 3+1. That's the whole point.
>
> It's about teamwork and eyes on by more than just one person, not about
> making it impossible to work. If you do a PR and JL *and* Romain ack it
> then where is the issue with that?
>
> You're seeing it, or making it sound, way more complicated than it is.
> Right now there is *no* consensus. Right now anyone can commit at any time
> without eyes on by anyone else. Right now if David doesn't like it 9 hours
> later, then he can just *trash* it as he sees fit.
>
> So, a 3+1 commit with no time frame makes a lot of sense imo. It's little
> more than a PR with peer review.
>
> Andy.
>
> On 8 July 2017 at 00:17, Mark Struberg <st...@yahoo.de.invalid> wrote:
>
>> Just for sake of clarifying the procedural stuff. A consensus vote
>> requires that the majority of PMC members did vote.
>> Consider I commit something and ping lt's say JL and Romain via IRC to ack
>> it. They send their +1 in the frame 1 minute after my PR. Then I go on and
>> push it. Now 9 hours later David awakes over in US and he doesn't like it.
>> He might vote -1, but it's already committed. Not what's intended, isn't?
>>
>> A VOTE without any time frame or a quorum does make little sense imo.
>>
>> LieGrue,
>> strub
>>
>>> Am 07.07.2017 um 16:25 schrieb Andy Gumbrecht <agumbrecht@tomitribe.com
>>> :
>>>
>>> This is not a vote for a release, if you get 3+1s within a minute then
>> you
>>> don't have to wait 72h. It is 'Consensus Approval'.
>>>
>>> Consensus Approval
>>> 'Consensus approval' refers to a vote (sense 1) which has *completed
>> *with
>>> at least three binding +1 votes and no vetos
>>>
>>> On 7 July 2017 at 16:19, Mark Struberg <st...@yahoo.de.invalid>
>> wrote:
>>>
>>>> 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 <
>> agumbrecht@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 <st...@yahoo.de.invalid>
>>>> wrote:
>>>>>
>>>>>> +1 well said, Jeff!
>>>>>>
>>>>>> LieGrue,
>>>>>> strub
>>>>>>
>>>>>>> Am 06.07.2017 um 18:37 schrieb Jeff Genender <jg...@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 <
>> agumbrecht@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.gallimore@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
>>>>>> <st...@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 <
>>>>>>>>> rmannibucau@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.gallimore@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 <
>>>>>>>>>> rmannibucau@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> 2017-07-05 10:00 GMT+02:00 Gurkan Erdogdu <
>>>> gurkanerdogdu@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
>>>>>> <
>>>>>>>>>>>>>> rmannibucau@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 <
>>>> gurkanerdogdu@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
>>>>>>>>>>>>>>> <st...@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.gallimore@gmail.com>:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Mon, Jul 3, 2017 at 2:04 AM, David Blevins <
>>>>>>>>>>>>> david.blevins@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
>>>>
>>>>
>>>
>>>
>>> --
>>> Andy Gumbrecht
>>> https://twitter.com/AndyGeeDe
>>> http://www.tomitribe.com
>>
>>
>
>
> --
> Andy Gumbrecht
> https://twitter.com/AndyGeeDe
> http://www.tomitribe.com
Re: [Discuss] Review-than-commit 3 month trial
Posted by Andy Gumbrecht <ag...@tomitribe.com>.
That's *not* how a consensus vote works. An RTC commit does not need a
majority at all - That would be a 'Majority Approval', and of course *that*
is not any use at all for RTC.
No one here is suggesting it that way, and it would be stupid to make
anyone wait 72h for a simple review. It is not stupid to say create a PR
and have someone else review it - That's the workflow on just about every
community git project out there - Don't merge your own PR is a really
common process.
If David comes on 9 hrs later and doesn't like it then he'd need to submit
a counter PR, and that would also need 3+1. That's the whole point.
It's about teamwork and eyes on by more than just one person, not about
making it impossible to work. If you do a PR and JL *and* Romain ack it
then where is the issue with that?
You're seeing it, or making it sound, way more complicated than it is.
Right now there is *no* consensus. Right now anyone can commit at any time
without eyes on by anyone else. Right now if David doesn't like it 9 hours
later, then he can just *trash* it as he sees fit.
So, a 3+1 commit with no time frame makes a lot of sense imo. It's little
more than a PR with peer review.
Andy.
On 8 July 2017 at 00:17, Mark Struberg <st...@yahoo.de.invalid> wrote:
> Just for sake of clarifying the procedural stuff. A consensus vote
> requires that the majority of PMC members did vote.
> Consider I commit something and ping lt's say JL and Romain via IRC to ack
> it. They send their +1 in the frame 1 minute after my PR. Then I go on and
> push it. Now 9 hours later David awakes over in US and he doesn't like it.
> He might vote -1, but it's already committed. Not what's intended, isn't?
>
> A VOTE without any time frame or a quorum does make little sense imo.
>
> LieGrue,
> strub
>
> > Am 07.07.2017 um 16:25 schrieb Andy Gumbrecht <agumbrecht@tomitribe.com
> >:
> >
> > This is not a vote for a release, if you get 3+1s within a minute then
> you
> > don't have to wait 72h. It is 'Consensus Approval'.
> >
> > Consensus Approval
> > 'Consensus approval' refers to a vote (sense 1) which has *completed
> *with
> > at least three binding +1 votes and no vetos
> >
> > On 7 July 2017 at 16:19, Mark Struberg <st...@yahoo.de.invalid>
> wrote:
> >
> >> 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 <
> agumbrecht@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 <st...@yahoo.de.invalid>
> >> wrote:
> >>>
> >>>> +1 well said, Jeff!
> >>>>
> >>>> LieGrue,
> >>>> strub
> >>>>
> >>>>> Am 06.07.2017 um 18:37 schrieb Jeff Genender <jg...@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 <
> agumbrecht@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.gallimore@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
> >>>> <st...@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 <
> >>>>>>> rmannibucau@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.gallimore@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 <
> >>>>>>>> rmannibucau@gmail.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> 2017-07-05 10:00 GMT+02:00 Gurkan Erdogdu <
> >> gurkanerdogdu@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
> >>>> <
> >>>>>>>>>>>> rmannibucau@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 <
> >> gurkanerdogdu@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
> >>>>>>>>>>>>> <st...@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.gallimore@gmail.com>:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Mon, Jul 3, 2017 at 2:04 AM, David Blevins <
> >>>>>>>>>>> david.blevins@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
> >>
> >>
> >
> >
> > --
> > Andy Gumbrecht
> > https://twitter.com/AndyGeeDe
> > http://www.tomitribe.com
>
>
--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
Re: [Discuss] Review-than-commit 3 month trial
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
Just for sake of clarifying the procedural stuff. A consensus vote requires that the majority of PMC members did vote.
Consider I commit something and ping lt's say JL and Romain via IRC to ack it. They send their +1 in the frame 1 minute after my PR. Then I go on and push it. Now 9 hours later David awakes over in US and he doesn't like it. He might vote -1, but it's already committed. Not what's intended, isn't?
A VOTE without any time frame or a quorum does make little sense imo.
LieGrue,
strub
> Am 07.07.2017 um 16:25 schrieb Andy Gumbrecht <ag...@tomitribe.com>:
>
> This is not a vote for a release, if you get 3+1s within a minute then you
> don't have to wait 72h. It is 'Consensus Approval'.
>
> Consensus Approval
> 'Consensus approval' refers to a vote (sense 1) which has *completed *with
> at least three binding +1 votes and no vetos
>
> On 7 July 2017 at 16:19, Mark Struberg <st...@yahoo.de.invalid> wrote:
>
>> 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 <agumbrecht@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 <st...@yahoo.de.invalid>
>> wrote:
>>>
>>>> +1 well said, Jeff!
>>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>>> Am 06.07.2017 um 18:37 schrieb Jeff Genender <jg...@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 <ag...@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.gallimore@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
>>>> <st...@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 <
>>>>>>> rmannibucau@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.gallimore@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 <
>>>>>>>> rmannibucau@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> 2017-07-05 10:00 GMT+02:00 Gurkan Erdogdu <
>> gurkanerdogdu@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
>>>> <
>>>>>>>>>>>> rmannibucau@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 <
>> gurkanerdogdu@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
>>>>>>>>>>>>> <st...@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.gallimore@gmail.com>:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Jul 3, 2017 at 2:04 AM, David Blevins <
>>>>>>>>>>> david.blevins@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
>>
>>
>
>
> --
> Andy Gumbrecht
> https://twitter.com/AndyGeeDe
> http://www.tomitribe.com
Re: [Discuss] Review-than-commit 3 month trial
Posted by Andy Gumbrecht <ag...@tomitribe.com>.
@Jonathan +1
On 7 July 2017 at 16:48, Jonathan Gallimore <jo...@gmail.com>
wrote:
> Some discussion as to what the process might be is probably pretty
> fundamental to help decide whether its beneficial to project or not. If the
> proposal was to have 20 +1s and a three week minimum voting period, you
> might have a different opinion to a process that requires 3 +1s with no
> minimum voting period (even if your thoughts were 'heck no' and 'no'
> respectively).
>
> Jon
>
> On Fri, Jul 7, 2017 at 3:43 PM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > @Andy: discussion is not if the process is easy or not but if it would be
> > beneficial to the project.
> >
> >
> > 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:40 GMT+02:00 Andy Gumbrecht <ag...@tomitribe.com>:
> >
> > > If someone comes up 'after' the Consensus Approval (3+1) with a -1 then
> > > they must submit a counter PR, that must also pass the RTC.
> > >
> > > It's pretty straight forward.
> > >
> > > On 7 July 2017 at 16:36, Andy Gumbrecht <ag...@tomitribe.com>
> > wrote:
> > >
> > > > ;-)
> > > >
> > > > On 7 July 2017 at 16:34, Andy Gumbrecht <ag...@tomitribe.com>
> > > wrote:
> > > >
> > > >> RTC is Consensus Approval and does not need 72h, just 3+1 in any
> > amount
> > > >> of time.
> > > >>
> > > >> On 7 July 2017 at 16:33, Andy Gumbrecht <ag...@tomitribe.com>
> > > wrote:
> > > >>
> > > >>> Those quotes are from Apache.
> > > >>>
> > > >>> On 7 July 2017 at 16:30, Romain Manni-Bucau <rmannibucau@gmail.com
> >
> > > >>> wrote:
> > > >>>
> > > >>>> What Mark meant is if we go through a "vote" then we need to
> comply
> > to
> > > >>>> ASF
> > > >>>> rules. Otherwise anything is up to the project and not a "vote".
> > > >>>> #semantic
> > > >>>> ;)
> > > >>>>
> > > >>>>
> > > >>>> 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:28 GMT+02:00 Andy Gumbrecht <
> agumbrecht@tomitribe.com
> > >:
> > > >>>>
> > > >>>> > A release is:
> > > >>>> >
> > > >>>> > Majority Approval
> > > >>>> > Refers to a vote (sense 1) which has completed with at least
> three
> > > >>>> binding
> > > >>>> > +1 votes and more +1 votes than -1 votes - You have to wait 72h.
> > > >>>> >
> > > >>>> > On 7 July 2017 at 16:25, Andy Gumbrecht <
> agumbrecht@tomitribe.com
> > >
> > > >>>> wrote:
> > > >>>> >
> > > >>>> > > This is not a vote for a release, if you get 3+1s within a
> > minute
> > > >>>> then
> > > >>>> > you
> > > >>>> > > don't have to wait 72h. It is 'Consensus Approval'.
> > > >>>> > >
> > > >>>> > > Consensus Approval
> > > >>>> > > 'Consensus approval' refers to a vote (sense 1) which has
> > > *completed
> > > >>>> > *with
> > > >>>> > > at least three binding +1 votes and no vetos
> > > >>>> > >
> > > >>>> > > On 7 July 2017 at 16:19, Mark Struberg
> > <struberg@yahoo.de.invalid
> > > >
> > > >>>> > wrote:
> > > >>>> > >
> > > >>>> > >> 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 <
> > > >>>> > agumbrecht@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
> > > <struberg@yahoo.de.invalid
> > > >>>> >
> > > >>>> > >> wrote:
> > > >>>> > >> >
> > > >>>> > >> >> +1 well said, Jeff!
> > > >>>> > >> >>
> > > >>>> > >> >> LieGrue,
> > > >>>> > >> >> strub
> > > >>>> > >> >>
> > > >>>> > >> >>> Am 06.07.2017 um 18:37 schrieb Jeff Genender <
> > > >>>> jgenender@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 <
> > > >>>> > agumbrecht@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.gallimore@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
> > > >>>> > >> >> <st...@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 <
> > > >>>> > >> >>>>> rmannibucau@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.gallimore@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 <
> > > >>>> > >> >>>>>> rmannibucau@gmail.com>
> > > >>>> > >> >>>>>>>> wrote:
> > > >>>> > >> >>>>>>>>
> > > >>>> > >> >>>>>>>>> 2017-07-05 10:00 GMT+02:00 Gurkan Erdogdu <
> > > >>>> > >> gurkanerdogdu@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
> > > >>>> > >> >> <
> > > >>>> > >> >>>>>>>>>> rmannibucau@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 <
> > > >>>> > >> gurkanerdogdu@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
> > > >>>> > >> >>>>>>>>>>> <st...@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.gallimore@gmail.com>:
> > > >>>> > >> >>>>>>>>>>>>
> > > >>>> > >> >>>>>>>>>>>> On Mon, Jul 3, 2017 at 2:04 AM, David Blevins <
> > > >>>> > >> >>>>>>>>> david.blevins@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
> > > >>>> > >>
> > > >>>> > >>
> > > >>>> > >
> > > >>>> > >
> > > >>>> > > --
> > > >>>> > > Andy Gumbrecht
> > > >>>> > > https://twitter.com/AndyGeeDe
> > > >>>> > > http://www.tomitribe.com
> > > >>>> > >
> > > >>>> >
> > > >>>> >
> > > >>>> >
> > > >>>> > --
> > > >>>> > Andy Gumbrecht
> > > >>>> > https://twitter.com/AndyGeeDe
> > > >>>> > http://www.tomitribe.com
> > > >>>> >
> > > >>>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> --
> > > >>> Andy Gumbrecht
> > > >>> https://twitter.com/AndyGeeDe
> > > >>> http://www.tomitribe.com
> > > >>>
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Andy Gumbrecht
> > > >> https://twitter.com/AndyGeeDe
> > > >> http://www.tomitribe.com
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Andy Gumbrecht
> > > > https://twitter.com/AndyGeeDe
> > > > http://www.tomitribe.com
> > > >
> > >
> > >
> > >
> > > --
> > > Andy Gumbrecht
> > > https://twitter.com/AndyGeeDe
> > > http://www.tomitribe.com
> > >
> >
>
--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
Re: [Discuss] Review-than-commit 3 month trial
Posted by Jonathan Gallimore <jo...@gmail.com>.
Some discussion as to what the process might be is probably pretty
fundamental to help decide whether its beneficial to project or not. If the
proposal was to have 20 +1s and a three week minimum voting period, you
might have a different opinion to a process that requires 3 +1s with no
minimum voting period (even if your thoughts were 'heck no' and 'no'
respectively).
Jon
On Fri, Jul 7, 2017 at 3:43 PM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> @Andy: discussion is not if the process is easy or not but if it would be
> beneficial to the project.
>
>
> 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:40 GMT+02:00 Andy Gumbrecht <ag...@tomitribe.com>:
>
> > If someone comes up 'after' the Consensus Approval (3+1) with a -1 then
> > they must submit a counter PR, that must also pass the RTC.
> >
> > It's pretty straight forward.
> >
> > On 7 July 2017 at 16:36, Andy Gumbrecht <ag...@tomitribe.com>
> wrote:
> >
> > > ;-)
> > >
> > > On 7 July 2017 at 16:34, Andy Gumbrecht <ag...@tomitribe.com>
> > wrote:
> > >
> > >> RTC is Consensus Approval and does not need 72h, just 3+1 in any
> amount
> > >> of time.
> > >>
> > >> On 7 July 2017 at 16:33, Andy Gumbrecht <ag...@tomitribe.com>
> > wrote:
> > >>
> > >>> Those quotes are from Apache.
> > >>>
> > >>> On 7 July 2017 at 16:30, Romain Manni-Bucau <rm...@gmail.com>
> > >>> wrote:
> > >>>
> > >>>> What Mark meant is if we go through a "vote" then we need to comply
> to
> > >>>> ASF
> > >>>> rules. Otherwise anything is up to the project and not a "vote".
> > >>>> #semantic
> > >>>> ;)
> > >>>>
> > >>>>
> > >>>> 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:28 GMT+02:00 Andy Gumbrecht <agumbrecht@tomitribe.com
> >:
> > >>>>
> > >>>> > A release is:
> > >>>> >
> > >>>> > Majority Approval
> > >>>> > Refers to a vote (sense 1) which has completed with at least three
> > >>>> binding
> > >>>> > +1 votes and more +1 votes than -1 votes - You have to wait 72h.
> > >>>> >
> > >>>> > On 7 July 2017 at 16:25, Andy Gumbrecht <agumbrecht@tomitribe.com
> >
> > >>>> wrote:
> > >>>> >
> > >>>> > > This is not a vote for a release, if you get 3+1s within a
> minute
> > >>>> then
> > >>>> > you
> > >>>> > > don't have to wait 72h. It is 'Consensus Approval'.
> > >>>> > >
> > >>>> > > Consensus Approval
> > >>>> > > 'Consensus approval' refers to a vote (sense 1) which has
> > *completed
> > >>>> > *with
> > >>>> > > at least three binding +1 votes and no vetos
> > >>>> > >
> > >>>> > > On 7 July 2017 at 16:19, Mark Struberg
> <struberg@yahoo.de.invalid
> > >
> > >>>> > wrote:
> > >>>> > >
> > >>>> > >> 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 <
> > >>>> > agumbrecht@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
> > <struberg@yahoo.de.invalid
> > >>>> >
> > >>>> > >> wrote:
> > >>>> > >> >
> > >>>> > >> >> +1 well said, Jeff!
> > >>>> > >> >>
> > >>>> > >> >> LieGrue,
> > >>>> > >> >> strub
> > >>>> > >> >>
> > >>>> > >> >>> Am 06.07.2017 um 18:37 schrieb Jeff Genender <
> > >>>> jgenender@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 <
> > >>>> > agumbrecht@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.gallimore@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
> > >>>> > >> >> <st...@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 <
> > >>>> > >> >>>>> rmannibucau@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.gallimore@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 <
> > >>>> > >> >>>>>> rmannibucau@gmail.com>
> > >>>> > >> >>>>>>>> wrote:
> > >>>> > >> >>>>>>>>
> > >>>> > >> >>>>>>>>> 2017-07-05 10:00 GMT+02:00 Gurkan Erdogdu <
> > >>>> > >> gurkanerdogdu@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
> > >>>> > >> >> <
> > >>>> > >> >>>>>>>>>> rmannibucau@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 <
> > >>>> > >> gurkanerdogdu@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
> > >>>> > >> >>>>>>>>>>> <st...@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.gallimore@gmail.com>:
> > >>>> > >> >>>>>>>>>>>>
> > >>>> > >> >>>>>>>>>>>> On Mon, Jul 3, 2017 at 2:04 AM, David Blevins <
> > >>>> > >> >>>>>>>>> david.blevins@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
> > >>>> > >>
> > >>>> > >>
> > >>>> > >
> > >>>> > >
> > >>>> > > --
> > >>>> > > Andy Gumbrecht
> > >>>> > > https://twitter.com/AndyGeeDe
> > >>>> > > http://www.tomitribe.com
> > >>>> > >
> > >>>> >
> > >>>> >
> > >>>> >
> > >>>> > --
> > >>>> > Andy Gumbrecht
> > >>>> > https://twitter.com/AndyGeeDe
> > >>>> > http://www.tomitribe.com
> > >>>> >
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> Andy Gumbrecht
> > >>> https://twitter.com/AndyGeeDe
> > >>> http://www.tomitribe.com
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >> Andy Gumbrecht
> > >> https://twitter.com/AndyGeeDe
> > >> http://www.tomitribe.com
> > >>
> > >
> > >
> > >
> > > --
> > > Andy Gumbrecht
> > > https://twitter.com/AndyGeeDe
> > > http://www.tomitribe.com
> > >
> >
> >
> >
> > --
> > Andy Gumbrecht
> > https://twitter.com/AndyGeeDe
> > http://www.tomitribe.com
> >
>
Re: [Discuss] Review-than-commit 3 month trial
Posted by Romain Manni-Bucau <rm...@gmail.com>.
@Andy: discussion is not if the process is easy or not but if it would be
beneficial to the project.
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:40 GMT+02:00 Andy Gumbrecht <ag...@tomitribe.com>:
> If someone comes up 'after' the Consensus Approval (3+1) with a -1 then
> they must submit a counter PR, that must also pass the RTC.
>
> It's pretty straight forward.
>
> On 7 July 2017 at 16:36, Andy Gumbrecht <ag...@tomitribe.com> wrote:
>
> > ;-)
> >
> > On 7 July 2017 at 16:34, Andy Gumbrecht <ag...@tomitribe.com>
> wrote:
> >
> >> RTC is Consensus Approval and does not need 72h, just 3+1 in any amount
> >> of time.
> >>
> >> On 7 July 2017 at 16:33, Andy Gumbrecht <ag...@tomitribe.com>
> wrote:
> >>
> >>> Those quotes are from Apache.
> >>>
> >>> On 7 July 2017 at 16:30, Romain Manni-Bucau <rm...@gmail.com>
> >>> wrote:
> >>>
> >>>> What Mark meant is if we go through a "vote" then we need to comply to
> >>>> ASF
> >>>> rules. Otherwise anything is up to the project and not a "vote".
> >>>> #semantic
> >>>> ;)
> >>>>
> >>>>
> >>>> 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:28 GMT+02:00 Andy Gumbrecht <ag...@tomitribe.com>:
> >>>>
> >>>> > A release is:
> >>>> >
> >>>> > Majority Approval
> >>>> > Refers to a vote (sense 1) which has completed with at least three
> >>>> binding
> >>>> > +1 votes and more +1 votes than -1 votes - You have to wait 72h.
> >>>> >
> >>>> > On 7 July 2017 at 16:25, Andy Gumbrecht <ag...@tomitribe.com>
> >>>> wrote:
> >>>> >
> >>>> > > This is not a vote for a release, if you get 3+1s within a minute
> >>>> then
> >>>> > you
> >>>> > > don't have to wait 72h. It is 'Consensus Approval'.
> >>>> > >
> >>>> > > Consensus Approval
> >>>> > > 'Consensus approval' refers to a vote (sense 1) which has
> *completed
> >>>> > *with
> >>>> > > at least three binding +1 votes and no vetos
> >>>> > >
> >>>> > > On 7 July 2017 at 16:19, Mark Struberg <struberg@yahoo.de.invalid
> >
> >>>> > wrote:
> >>>> > >
> >>>> > >> 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 <
> >>>> > agumbrecht@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
> <struberg@yahoo.de.invalid
> >>>> >
> >>>> > >> wrote:
> >>>> > >> >
> >>>> > >> >> +1 well said, Jeff!
> >>>> > >> >>
> >>>> > >> >> LieGrue,
> >>>> > >> >> strub
> >>>> > >> >>
> >>>> > >> >>> Am 06.07.2017 um 18:37 schrieb Jeff Genender <
> >>>> jgenender@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 <
> >>>> > agumbrecht@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.gallimore@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
> >>>> > >> >> <st...@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 <
> >>>> > >> >>>>> rmannibucau@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.gallimore@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 <
> >>>> > >> >>>>>> rmannibucau@gmail.com>
> >>>> > >> >>>>>>>> wrote:
> >>>> > >> >>>>>>>>
> >>>> > >> >>>>>>>>> 2017-07-05 10:00 GMT+02:00 Gurkan Erdogdu <
> >>>> > >> gurkanerdogdu@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
> >>>> > >> >> <
> >>>> > >> >>>>>>>>>> rmannibucau@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 <
> >>>> > >> gurkanerdogdu@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
> >>>> > >> >>>>>>>>>>> <st...@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.gallimore@gmail.com>:
> >>>> > >> >>>>>>>>>>>>
> >>>> > >> >>>>>>>>>>>> On Mon, Jul 3, 2017 at 2:04 AM, David Blevins <
> >>>> > >> >>>>>>>>> david.blevins@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
> >>>> > >>
> >>>> > >>
> >>>> > >
> >>>> > >
> >>>> > > --
> >>>> > > Andy Gumbrecht
> >>>> > > https://twitter.com/AndyGeeDe
> >>>> > > http://www.tomitribe.com
> >>>> > >
> >>>> >
> >>>> >
> >>>> >
> >>>> > --
> >>>> > Andy Gumbrecht
> >>>> > https://twitter.com/AndyGeeDe
> >>>> > http://www.tomitribe.com
> >>>> >
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Andy Gumbrecht
> >>> https://twitter.com/AndyGeeDe
> >>> http://www.tomitribe.com
> >>>
> >>
> >>
> >>
> >> --
> >> Andy Gumbrecht
> >> https://twitter.com/AndyGeeDe
> >> http://www.tomitribe.com
> >>
> >
> >
> >
> > --
> > Andy Gumbrecht
> > https://twitter.com/AndyGeeDe
> > http://www.tomitribe.com
> >
>
>
>
> --
> Andy Gumbrecht
> https://twitter.com/AndyGeeDe
> http://www.tomitribe.com
>
Re: [Discuss] Review-than-commit 3 month trial
Posted by Andy Gumbrecht <ag...@tomitribe.com>.
If someone comes up 'after' the Consensus Approval (3+1) with a -1 then
they must submit a counter PR, that must also pass the RTC.
It's pretty straight forward.
On 7 July 2017 at 16:36, Andy Gumbrecht <ag...@tomitribe.com> wrote:
> ;-)
>
> On 7 July 2017 at 16:34, Andy Gumbrecht <ag...@tomitribe.com> wrote:
>
>> RTC is Consensus Approval and does not need 72h, just 3+1 in any amount
>> of time.
>>
>> On 7 July 2017 at 16:33, Andy Gumbrecht <ag...@tomitribe.com> wrote:
>>
>>> Those quotes are from Apache.
>>>
>>> On 7 July 2017 at 16:30, Romain Manni-Bucau <rm...@gmail.com>
>>> wrote:
>>>
>>>> What Mark meant is if we go through a "vote" then we need to comply to
>>>> ASF
>>>> rules. Otherwise anything is up to the project and not a "vote".
>>>> #semantic
>>>> ;)
>>>>
>>>>
>>>> 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:28 GMT+02:00 Andy Gumbrecht <ag...@tomitribe.com>:
>>>>
>>>> > A release is:
>>>> >
>>>> > Majority Approval
>>>> > Refers to a vote (sense 1) which has completed with at least three
>>>> binding
>>>> > +1 votes and more +1 votes than -1 votes - You have to wait 72h.
>>>> >
>>>> > On 7 July 2017 at 16:25, Andy Gumbrecht <ag...@tomitribe.com>
>>>> wrote:
>>>> >
>>>> > > This is not a vote for a release, if you get 3+1s within a minute
>>>> then
>>>> > you
>>>> > > don't have to wait 72h. It is 'Consensus Approval'.
>>>> > >
>>>> > > Consensus Approval
>>>> > > 'Consensus approval' refers to a vote (sense 1) which has *completed
>>>> > *with
>>>> > > at least three binding +1 votes and no vetos
>>>> > >
>>>> > > On 7 July 2017 at 16:19, Mark Struberg <st...@yahoo.de.invalid>
>>>> > wrote:
>>>> > >
>>>> > >> 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 <
>>>> > agumbrecht@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 <struberg@yahoo.de.invalid
>>>> >
>>>> > >> wrote:
>>>> > >> >
>>>> > >> >> +1 well said, Jeff!
>>>> > >> >>
>>>> > >> >> LieGrue,
>>>> > >> >> strub
>>>> > >> >>
>>>> > >> >>> Am 06.07.2017 um 18:37 schrieb Jeff Genender <
>>>> jgenender@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 <
>>>> > agumbrecht@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.gallimore@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
>>>> > >> >> <st...@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 <
>>>> > >> >>>>> rmannibucau@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.gallimore@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 <
>>>> > >> >>>>>> rmannibucau@gmail.com>
>>>> > >> >>>>>>>> wrote:
>>>> > >> >>>>>>>>
>>>> > >> >>>>>>>>> 2017-07-05 10:00 GMT+02:00 Gurkan Erdogdu <
>>>> > >> gurkanerdogdu@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
>>>> > >> >> <
>>>> > >> >>>>>>>>>> rmannibucau@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 <
>>>> > >> gurkanerdogdu@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
>>>> > >> >>>>>>>>>>> <st...@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.gallimore@gmail.com>:
>>>> > >> >>>>>>>>>>>>
>>>> > >> >>>>>>>>>>>> On Mon, Jul 3, 2017 at 2:04 AM, David Blevins <
>>>> > >> >>>>>>>>> david.blevins@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
>>>> > >>
>>>> > >>
>>>> > >
>>>> > >
>>>> > > --
>>>> > > Andy Gumbrecht
>>>> > > https://twitter.com/AndyGeeDe
>>>> > > http://www.tomitribe.com
>>>> > >
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Andy Gumbrecht
>>>> > https://twitter.com/AndyGeeDe
>>>> > http://www.tomitribe.com
>>>> >
>>>>
>>>
>>>
>>>
>>> --
>>> Andy Gumbrecht
>>> https://twitter.com/AndyGeeDe
>>> http://www.tomitribe.com
>>>
>>
>>
>>
>> --
>> Andy Gumbrecht
>> https://twitter.com/AndyGeeDe
>> http://www.tomitribe.com
>>
>
>
>
> --
> Andy Gumbrecht
> https://twitter.com/AndyGeeDe
> http://www.tomitribe.com
>
--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
Re: [Discuss] Review-than-commit 3 month trial
Posted by Andy Gumbrecht <ag...@tomitribe.com>.
;-)
On 7 July 2017 at 16:34, Andy Gumbrecht <ag...@tomitribe.com> wrote:
> RTC is Consensus Approval and does not need 72h, just 3+1 in any amount
> of time.
>
> On 7 July 2017 at 16:33, Andy Gumbrecht <ag...@tomitribe.com> wrote:
>
>> Those quotes are from Apache.
>>
>> On 7 July 2017 at 16:30, Romain Manni-Bucau <rm...@gmail.com>
>> wrote:
>>
>>> What Mark meant is if we go through a "vote" then we need to comply to
>>> ASF
>>> rules. Otherwise anything is up to the project and not a "vote".
>>> #semantic
>>> ;)
>>>
>>>
>>> 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:28 GMT+02:00 Andy Gumbrecht <ag...@tomitribe.com>:
>>>
>>> > A release is:
>>> >
>>> > Majority Approval
>>> > Refers to a vote (sense 1) which has completed with at least three
>>> binding
>>> > +1 votes and more +1 votes than -1 votes - You have to wait 72h.
>>> >
>>> > On 7 July 2017 at 16:25, Andy Gumbrecht <ag...@tomitribe.com>
>>> wrote:
>>> >
>>> > > This is not a vote for a release, if you get 3+1s within a minute
>>> then
>>> > you
>>> > > don't have to wait 72h. It is 'Consensus Approval'.
>>> > >
>>> > > Consensus Approval
>>> > > 'Consensus approval' refers to a vote (sense 1) which has *completed
>>> > *with
>>> > > at least three binding +1 votes and no vetos
>>> > >
>>> > > On 7 July 2017 at 16:19, Mark Struberg <st...@yahoo.de.invalid>
>>> > wrote:
>>> > >
>>> > >> 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 <
>>> > agumbrecht@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 <struberg@yahoo.de.invalid
>>> >
>>> > >> wrote:
>>> > >> >
>>> > >> >> +1 well said, Jeff!
>>> > >> >>
>>> > >> >> LieGrue,
>>> > >> >> strub
>>> > >> >>
>>> > >> >>> Am 06.07.2017 um 18:37 schrieb Jeff Genender <
>>> jgenender@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 <
>>> > agumbrecht@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.gallimore@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
>>> > >> >> <st...@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 <
>>> > >> >>>>> rmannibucau@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.gallimore@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 <
>>> > >> >>>>>> rmannibucau@gmail.com>
>>> > >> >>>>>>>> wrote:
>>> > >> >>>>>>>>
>>> > >> >>>>>>>>> 2017-07-05 10:00 GMT+02:00 Gurkan Erdogdu <
>>> > >> gurkanerdogdu@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
>>> > >> >> <
>>> > >> >>>>>>>>>> rmannibucau@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 <
>>> > >> gurkanerdogdu@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
>>> > >> >>>>>>>>>>> <st...@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.gallimore@gmail.com>:
>>> > >> >>>>>>>>>>>>
>>> > >> >>>>>>>>>>>> On Mon, Jul 3, 2017 at 2:04 AM, David Blevins <
>>> > >> >>>>>>>>> david.blevins@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
>>> > >>
>>> > >>
>>> > >
>>> > >
>>> > > --
>>> > > Andy Gumbrecht
>>> > > https://twitter.com/AndyGeeDe
>>> > > http://www.tomitribe.com
>>> > >
>>> >
>>> >
>>> >
>>> > --
>>> > Andy Gumbrecht
>>> > https://twitter.com/AndyGeeDe
>>> > http://www.tomitribe.com
>>> >
>>>
>>
>>
>>
>> --
>> Andy Gumbrecht
>> https://twitter.com/AndyGeeDe
>> http://www.tomitribe.com
>>
>
>
>
> --
> Andy Gumbrecht
> https://twitter.com/AndyGeeDe
> http://www.tomitribe.com
>
--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
Re: [Discuss] Review-than-commit 3 month trial
Posted by Andy Gumbrecht <ag...@tomitribe.com>.
RTC is Consensus Approval and does not need 72h, just 3+1 in any amount of
time.
On 7 July 2017 at 16:33, Andy Gumbrecht <ag...@tomitribe.com> wrote:
> Those quotes are from Apache.
>
> On 7 July 2017 at 16:30, Romain Manni-Bucau <rm...@gmail.com> wrote:
>
>> What Mark meant is if we go through a "vote" then we need to comply to ASF
>> rules. Otherwise anything is up to the project and not a "vote". #semantic
>> ;)
>>
>>
>> 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:28 GMT+02:00 Andy Gumbrecht <ag...@tomitribe.com>:
>>
>> > A release is:
>> >
>> > Majority Approval
>> > Refers to a vote (sense 1) which has completed with at least three
>> binding
>> > +1 votes and more +1 votes than -1 votes - You have to wait 72h.
>> >
>> > On 7 July 2017 at 16:25, Andy Gumbrecht <ag...@tomitribe.com>
>> wrote:
>> >
>> > > This is not a vote for a release, if you get 3+1s within a minute then
>> > you
>> > > don't have to wait 72h. It is 'Consensus Approval'.
>> > >
>> > > Consensus Approval
>> > > 'Consensus approval' refers to a vote (sense 1) which has *completed
>> > *with
>> > > at least three binding +1 votes and no vetos
>> > >
>> > > On 7 July 2017 at 16:19, Mark Struberg <st...@yahoo.de.invalid>
>> > wrote:
>> > >
>> > >> 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 <
>> > agumbrecht@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 <st...@yahoo.de.invalid>
>> > >> wrote:
>> > >> >
>> > >> >> +1 well said, Jeff!
>> > >> >>
>> > >> >> LieGrue,
>> > >> >> strub
>> > >> >>
>> > >> >>> Am 06.07.2017 um 18:37 schrieb Jeff Genender <
>> jgenender@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 <
>> > agumbrecht@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.gallimore@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
>> > >> >> <st...@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 <
>> > >> >>>>> rmannibucau@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.gallimore@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 <
>> > >> >>>>>> rmannibucau@gmail.com>
>> > >> >>>>>>>> wrote:
>> > >> >>>>>>>>
>> > >> >>>>>>>>> 2017-07-05 10:00 GMT+02:00 Gurkan Erdogdu <
>> > >> gurkanerdogdu@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
>> > >> >> <
>> > >> >>>>>>>>>> rmannibucau@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 <
>> > >> gurkanerdogdu@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
>> > >> >>>>>>>>>>> <st...@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.gallimore@gmail.com>:
>> > >> >>>>>>>>>>>>
>> > >> >>>>>>>>>>>> On Mon, Jul 3, 2017 at 2:04 AM, David Blevins <
>> > >> >>>>>>>>> david.blevins@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
>> > >>
>> > >>
>> > >
>> > >
>> > > --
>> > > Andy Gumbrecht
>> > > https://twitter.com/AndyGeeDe
>> > > http://www.tomitribe.com
>> > >
>> >
>> >
>> >
>> > --
>> > Andy Gumbrecht
>> > https://twitter.com/AndyGeeDe
>> > http://www.tomitribe.com
>> >
>>
>
>
>
> --
> Andy Gumbrecht
> https://twitter.com/AndyGeeDe
> http://www.tomitribe.com
>
--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
Re: [Discuss] Review-than-commit 3 month trial
Posted by Andy Gumbrecht <ag...@tomitribe.com>.
Those quotes are from Apache.
On 7 July 2017 at 16:30, Romain Manni-Bucau <rm...@gmail.com> wrote:
> What Mark meant is if we go through a "vote" then we need to comply to ASF
> rules. Otherwise anything is up to the project and not a "vote". #semantic
> ;)
>
>
> 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:28 GMT+02:00 Andy Gumbrecht <ag...@tomitribe.com>:
>
> > A release is:
> >
> > Majority Approval
> > Refers to a vote (sense 1) which has completed with at least three
> binding
> > +1 votes and more +1 votes than -1 votes - You have to wait 72h.
> >
> > On 7 July 2017 at 16:25, Andy Gumbrecht <ag...@tomitribe.com>
> wrote:
> >
> > > This is not a vote for a release, if you get 3+1s within a minute then
> > you
> > > don't have to wait 72h. It is 'Consensus Approval'.
> > >
> > > Consensus Approval
> > > 'Consensus approval' refers to a vote (sense 1) which has *completed
> > *with
> > > at least three binding +1 votes and no vetos
> > >
> > > On 7 July 2017 at 16:19, Mark Struberg <st...@yahoo.de.invalid>
> > wrote:
> > >
> > >> 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 <
> > agumbrecht@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 <st...@yahoo.de.invalid>
> > >> wrote:
> > >> >
> > >> >> +1 well said, Jeff!
> > >> >>
> > >> >> LieGrue,
> > >> >> strub
> > >> >>
> > >> >>> Am 06.07.2017 um 18:37 schrieb Jeff Genender <
> jgenender@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 <
> > agumbrecht@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.gallimore@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
> > >> >> <st...@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 <
> > >> >>>>> rmannibucau@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.gallimore@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 <
> > >> >>>>>> rmannibucau@gmail.com>
> > >> >>>>>>>> wrote:
> > >> >>>>>>>>
> > >> >>>>>>>>> 2017-07-05 10:00 GMT+02:00 Gurkan Erdogdu <
> > >> gurkanerdogdu@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
> > >> >> <
> > >> >>>>>>>>>> rmannibucau@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 <
> > >> gurkanerdogdu@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
> > >> >>>>>>>>>>> <st...@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.gallimore@gmail.com>:
> > >> >>>>>>>>>>>>
> > >> >>>>>>>>>>>> On Mon, Jul 3, 2017 at 2:04 AM, David Blevins <
> > >> >>>>>>>>> david.blevins@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
> > >>
> > >>
> > >
> > >
> > > --
> > > Andy Gumbrecht
> > > https://twitter.com/AndyGeeDe
> > > http://www.tomitribe.com
> > >
> >
> >
> >
> > --
> > Andy Gumbrecht
> > https://twitter.com/AndyGeeDe
> > http://www.tomitribe.com
> >
>
--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
Re: [Discuss] Review-than-commit 3 month trial
Posted by Romain Manni-Bucau <rm...@gmail.com>.
What Mark meant is if we go through a "vote" then we need to comply to ASF
rules. Otherwise anything is up to the project and not a "vote". #semantic
;)
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:28 GMT+02:00 Andy Gumbrecht <ag...@tomitribe.com>:
> A release is:
>
> Majority Approval
> Refers to a vote (sense 1) which has completed with at least three binding
> +1 votes and more +1 votes than -1 votes - You have to wait 72h.
>
> On 7 July 2017 at 16:25, Andy Gumbrecht <ag...@tomitribe.com> wrote:
>
> > This is not a vote for a release, if you get 3+1s within a minute then
> you
> > don't have to wait 72h. It is 'Consensus Approval'.
> >
> > Consensus Approval
> > 'Consensus approval' refers to a vote (sense 1) which has *completed
> *with
> > at least three binding +1 votes and no vetos
> >
> > On 7 July 2017 at 16:19, Mark Struberg <st...@yahoo.de.invalid>
> wrote:
> >
> >> 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 <
> agumbrecht@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 <st...@yahoo.de.invalid>
> >> wrote:
> >> >
> >> >> +1 well said, Jeff!
> >> >>
> >> >> LieGrue,
> >> >> strub
> >> >>
> >> >>> Am 06.07.2017 um 18:37 schrieb Jeff Genender <jgenender@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 <
> agumbrecht@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.gallimore@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
> >> >> <st...@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 <
> >> >>>>> rmannibucau@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.gallimore@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 <
> >> >>>>>> rmannibucau@gmail.com>
> >> >>>>>>>> wrote:
> >> >>>>>>>>
> >> >>>>>>>>> 2017-07-05 10:00 GMT+02:00 Gurkan Erdogdu <
> >> gurkanerdogdu@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
> >> >> <
> >> >>>>>>>>>> rmannibucau@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 <
> >> gurkanerdogdu@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
> >> >>>>>>>>>>> <st...@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.gallimore@gmail.com>:
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> On Mon, Jul 3, 2017 at 2:04 AM, David Blevins <
> >> >>>>>>>>> david.blevins@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
> >>
> >>
> >
> >
> > --
> > Andy Gumbrecht
> > https://twitter.com/AndyGeeDe
> > http://www.tomitribe.com
> >
>
>
>
> --
> Andy Gumbrecht
> https://twitter.com/AndyGeeDe
> http://www.tomitribe.com
>
Re: [Discuss] Review-than-commit 3 month trial
Posted by Andy Gumbrecht <ag...@tomitribe.com>.
A release is:
Majority Approval
Refers to a vote (sense 1) which has completed with at least three binding
+1 votes and more +1 votes than -1 votes - You have to wait 72h.
On 7 July 2017 at 16:25, Andy Gumbrecht <ag...@tomitribe.com> wrote:
> This is not a vote for a release, if you get 3+1s within a minute then you
> don't have to wait 72h. It is 'Consensus Approval'.
>
> Consensus Approval
> 'Consensus approval' refers to a vote (sense 1) which has *completed *with
> at least three binding +1 votes and no vetos
>
> On 7 July 2017 at 16:19, Mark Struberg <st...@yahoo.de.invalid> wrote:
>
>> 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 <agumbrecht@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 <st...@yahoo.de.invalid>
>> wrote:
>> >
>> >> +1 well said, Jeff!
>> >>
>> >> LieGrue,
>> >> strub
>> >>
>> >>> Am 06.07.2017 um 18:37 schrieb Jeff Genender <jg...@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 <agumbrecht@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.gallimore@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
>> >> <st...@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 <
>> >>>>> rmannibucau@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.gallimore@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 <
>> >>>>>> rmannibucau@gmail.com>
>> >>>>>>>> wrote:
>> >>>>>>>>
>> >>>>>>>>> 2017-07-05 10:00 GMT+02:00 Gurkan Erdogdu <
>> gurkanerdogdu@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
>> >> <
>> >>>>>>>>>> rmannibucau@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 <
>> gurkanerdogdu@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
>> >>>>>>>>>>> <st...@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.gallimore@gmail.com>:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> On Mon, Jul 3, 2017 at 2:04 AM, David Blevins <
>> >>>>>>>>> david.blevins@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
>>
>>
>
>
> --
> Andy Gumbrecht
> https://twitter.com/AndyGeeDe
> http://www.tomitribe.com
>
--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
Re: [Discuss] Review-than-commit 3 month trial
Posted by Andy Gumbrecht <ag...@tomitribe.com>.
This is not a vote for a release, if you get 3+1s within a minute then you
don't have to wait 72h. It is 'Consensus Approval'.
Consensus Approval
'Consensus approval' refers to a vote (sense 1) which has *completed *with
at least three binding +1 votes and no vetos
On 7 July 2017 at 16:19, Mark Struberg <st...@yahoo.de.invalid> wrote:
> 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 <agumbrecht@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 <st...@yahoo.de.invalid>
> wrote:
> >
> >> +1 well said, Jeff!
> >>
> >> LieGrue,
> >> strub
> >>
> >>> Am 06.07.2017 um 18:37 schrieb Jeff Genender <jg...@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 <ag...@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.gallimore@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
> >> <st...@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 <
> >>>>> rmannibucau@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.gallimore@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 <
> >>>>>> rmannibucau@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> 2017-07-05 10:00 GMT+02:00 Gurkan Erdogdu <
> gurkanerdogdu@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
> >> <
> >>>>>>>>>> rmannibucau@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 <
> gurkanerdogdu@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
> >>>>>>>>>>> <st...@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.gallimore@gmail.com>:
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Mon, Jul 3, 2017 at 2:04 AM, David Blevins <
> >>>>>>>>> david.blevins@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
>
>
--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
Re: [Discuss] Review-than-commit 3 month trial
Posted by Mark Struberg <st...@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 <ag...@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 <st...@yahoo.de.invalid> wrote:
>
>> +1 well said, Jeff!
>>
>> LieGrue,
>> strub
>>
>>> Am 06.07.2017 um 18:37 schrieb Jeff Genender <jg...@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 <ag...@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.gallimore@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
>> <st...@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 <
>>>>> rmannibucau@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.gallimore@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 <
>>>>>> rmannibucau@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> 2017-07-05 10:00 GMT+02:00 Gurkan Erdogdu <gurkanerdogdu@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
>> <
>>>>>>>>>> rmannibucau@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 <gurkanerdogdu@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
>>>>>>>>>>> <st...@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.gallimore@gmail.com>:
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Jul 3, 2017 at 2:04 AM, David Blevins <
>>>>>>>>> david.blevins@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
Re: [Discuss] Review-than-commit 3 month trial
Posted by Andy Gumbrecht <ag...@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 <st...@yahoo.de.invalid> wrote:
> +1 well said, Jeff!
>
> LieGrue,
> strub
>
> > Am 06.07.2017 um 18:37 schrieb Jeff Genender <jg...@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 <ag...@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.gallimore@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
> <st...@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 <
> >>> rmannibucau@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.gallimore@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 <
> >>>> rmannibucau@gmail.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> 2017-07-05 10:00 GMT+02:00 Gurkan Erdogdu <gurkanerdogdu@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
> <
> >>>>>>>> rmannibucau@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 <gurkanerdogdu@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
> >>>>>>>>> <st...@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.gallimore@gmail.com>:
> >>>>>>>>>>
> >>>>>>>>>> On Mon, Jul 3, 2017 at 2:04 AM, David Blevins <
> >>>>>>> david.blevins@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
Re: [Discuss] Review-than-commit 3 month trial
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
+1 well said, Jeff!
LieGrue,
strub
> Am 06.07.2017 um 18:37 schrieb Jeff Genender <jg...@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 <ag...@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 <jo...@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 <st...@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 <
>>> rmannibucau@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.gallimore@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 <
>>>> rmannibucau@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> 2017-07-05 10:00 GMT+02:00 Gurkan Erdogdu <gurkanerdogdu@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 <
>>>>>>>> rmannibucau@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 <gurkanerdogdu@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
>>>>>>>>> <st...@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.gallimore@gmail.com>:
>>>>>>>>>>
>>>>>>>>>> On Mon, Jul 3, 2017 at 2:04 AM, David Blevins <
>>>>>>> david.blevins@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
>
Re: [Discuss] Review-than-commit 3 month trial
Posted by Jeff Genender <jg...@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 <ag...@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 <jo...@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 <st...@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 <
>> rmannibucau@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.gallimore@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 <
>>> rmannibucau@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> 2017-07-05 10:00 GMT+02:00 Gurkan Erdogdu <gurkanerdogdu@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 <
>>>>>>> rmannibucau@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 <gurkanerdogdu@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
>>>>>>>> <st...@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.gallimore@gmail.com>:
>>>>>>>>>
>>>>>>>>> On Mon, Jul 3, 2017 at 2:04 AM, David Blevins <
>>>>>> david.blevins@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
Re: [Discuss] Review-than-commit 3 month trial
Posted by Andy Gumbrecht <ag...@tomitribe.com>.
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 <jo...@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 <st...@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 <
> rmannibucau@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.gallimore@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 <
> > rmannibucau@gmail.com>
> > >> wrote:
> > >>
> > >>> 2017-07-05 10:00 GMT+02:00 Gurkan Erdogdu <gurkanerdogdu@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 <
> > >>>> rmannibucau@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 <gurkanerdogdu@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
> > >>>>> <st...@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.gallimore@gmail.com>:
> > >>>>>>
> > >>>>>> On Mon, Jul 3, 2017 at 2:04 AM, David Blevins <
> > >>> david.blevins@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
Re: [Discuss] Review-than-commit 3 month trial
Posted by Jonathan Gallimore <jo...@gmail.com>.
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 <st...@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 <rmannibucau@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.gallimore@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 <
> rmannibucau@gmail.com>
> >> wrote:
> >>
> >>> 2017-07-05 10:00 GMT+02:00 Gurkan Erdogdu <gurkanerdogdu@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 <
> >>>> rmannibucau@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 <gurkanerdogdu@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
> >>>>> <st...@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.gallimore@gmail.com>:
> >>>>>>
> >>>>>> On Mon, Jul 3, 2017 at 2:04 AM, David Blevins <
> >>> david.blevins@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
> >>>>>
> >>>>
> >>>
> >>
>
>
Re: [Discuss] Review-than-commit 3 month trial
Posted by David Blevins <da...@gmail.com>.
I brought up RTC a few months ago as a way to get more dev list discussion, more people aware of the code going in and higher participation overall. The commit/revert ping-pong we had last week seemed to revive the topic.
I haven’t seen us properly applying RTC, which requires 3 +1s and no -1s.
--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
> On Jul 5, 2017, at 10:06 AM, Mark Struberg <st...@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 <rm...@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 <jo...@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 <rm...@gmail.com>
>>> wrote:
>>>
>>>> 2017-07-05 10:00 GMT+02:00 Gurkan Erdogdu <gurkanerdogdu@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 <
>>>>> rmannibucau@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 <gurkanerdogdu@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
>>>>>> <st...@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.gallimore@gmail.com>:
>>>>>>>
>>>>>>> On Mon, Jul 3, 2017 at 2:04 AM, David Blevins <
>>>> david.blevins@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
>>>>>>
>>>>>
>>>>
>>>
>
Re: [Discuss] Review-than-commit 3 month trial
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
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 <rm...@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 <jo...@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 <rm...@gmail.com>
>> wrote:
>>
>>> 2017-07-05 10:00 GMT+02:00 Gurkan Erdogdu <gurkanerdogdu@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 <
>>>> rmannibucau@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 <gurkanerdogdu@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
>>>>> <st...@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.gallimore@gmail.com>:
>>>>>>
>>>>>> On Mon, Jul 3, 2017 at 2:04 AM, David Blevins <
>>> david.blevins@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
>>>>>
>>>>
>>>
>>
Re: [Discuss] Review-than-commit 3 month trial
Posted by Romain Manni-Bucau <rm...@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 <jo...@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 <rm...@gmail.com>
> wrote:
>
> > 2017-07-05 10:00 GMT+02:00 Gurkan Erdogdu <gurkanerdogdu@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 <
> > > rmannibucau@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 <gurkanerdogdu@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
> > > > <st...@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.gallimore@gmail.com>:
> > > > >
> > > > > On Mon, Jul 3, 2017 at 2:04 AM, David Blevins <
> > david.blevins@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
> > > >
> > >
> >
>
Re: [Discuss] Review-than-commit 3 month trial
Posted by Jonathan Gallimore <jo...@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 <rm...@gmail.com>
wrote:
> 2017-07-05 10:00 GMT+02:00 Gurkan Erdogdu <gurkanerdogdu@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 <
> > rmannibucau@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 <gurkanerdogdu@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
> > > <st...@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.gallimore@gmail.com>:
> > > >
> > > > On Mon, Jul 3, 2017 at 2:04 AM, David Blevins <
> david.blevins@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
> > >
> >
>
Re: [Discuss] Review-than-commit 3 month trial
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2017-07-05 10:00 GMT+02:00 Gurkan Erdogdu <gu...@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 <
> rmannibucau@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 <gurkanerdogdu@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
> > <st...@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.gallimore@gmail.com>:
> > >
> > > On Mon, Jul 3, 2017 at 2:04 AM, David Blevins <david.blevins@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
> >
>
Re: [Discuss] Review-than-commit 3 month trial
Posted by Gurkan Erdogdu <gu...@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.
Regards.Gurkan-
On Wednesday, July 5, 2017, 10:13:22 AM GMT+3, Romain Manni-Bucau <rm...@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 <gu...@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
> <st...@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.gallimore@gmail.com>:
> >
> > On Mon, Jul 3, 2017 at 2:04 AM, David Blevins <da...@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
>
Re: [Discuss] Review-than-commit 3 month trial
Posted by Romain Manni-Bucau <rm...@gmail.com>.
@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 <gu...@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
> <st...@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.gallimore@gmail.com>:
> >
> > On Mon, Jul 3, 2017 at 2:04 AM, David Blevins <da...@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
>
Re: [Discuss] Review-than-commit 3 month trial
Posted by Gurkan Erdogdu <gu...@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 <st...@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 <jo...@gmail.com>:
>
> On Mon, Jul 3, 2017 at 2:04 AM, David Blevins <da...@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
Re: [Discuss] Review-than-commit 3 month trial
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
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 <jo...@gmail.com>:
>
> On Mon, Jul 3, 2017 at 2:04 AM, David Blevins <da...@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
Re: [Discuss] Review-than-commit 3 month trial
Posted by Jonathan Gallimore <jo...@gmail.com>.
On Mon, Jul 3, 2017 at 2:04 AM, David Blevins <da...@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
>
>
Re: [Discuss] Review-than-commit 3 month trial
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
We use already Github pull requests. The Apache integration is pretty good,
so I don't see any blockers.
I already reviewed and merged a couple of them.
See for example last week
https://issues.apache.org/jira/browse/TOMEE-2083
https://github.com/apache/tomee/pull/81
The comments on PRs are also synchonized into JIRA.
So not sure what we need more but use it.
In terms of RTC, I'm tempted to give a +0, not because I think it's a bad
thing, but because I fear I can't really help much in terms of reviews.
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Mon, Jul 3, 2017 at 8:34 AM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> I'm +1 to enhance our github support, it is really a favorable contribution
> solution but for the process itself I don't see what changed so I'm still
> -1 for the reasons mentionned when we discussed it.
>
>
> 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-03 3:04 GMT+02:00 David Blevins <da...@gmail.com>:
>
> > 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.
> >
> > 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.
> >
> > - Should all reviews be on the dev list? With Github PRs comments
> > and JIRA comments, there needs to be a source of truth.
> >
> > - Should we fully document the process before we try so we can get
> > the most value from a 3 month trial?
> >
> >
> > --
> > David Blevins
> > http://twitter.com/dblevins
> > http://www.tomitribe.com
> >
> >
>
Re: [Discuss] Review-than-commit 3 month trial
Posted by Romain Manni-Bucau <rm...@gmail.com>.
I'm +1 to enhance our github support, it is really a favorable contribution
solution but for the process itself I don't see what changed so I'm still
-1 for the reasons mentionned when we discussed it.
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-03 3:04 GMT+02:00 David Blevins <da...@gmail.com>:
> 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.
>
> 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.
>
> - Should all reviews be on the dev list? With Github PRs comments
> and JIRA comments, there needs to be a source of truth.
>
> - Should we fully document the process before we try so we can get
> the most value from a 3 month trial?
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
>
Re: [Discuss] Review-than-commit 3 month trial
Posted by Andy Gumbrecht <ag...@tomitribe.com>.
+1 for option 1 - I feel rtc should be little more than the 'PR with peer
review' option, which is the goal (don't merge your own commits without
several eyes on, etc.).
-1 for any defined waiting period for the +1s. I'd not want to see rtc
stopping anyone from getting things done quickly, just not autonomously.
If there is a veto 'after' a commit (but within 72h of the commit) then the
revert must happen as defined by the rules. This would then be reworked so
the the veto issue is addressed, or (if no rtc agreement can be achieved)
put to a majority vote.
If a veto is not performed within 24h, then the commit is final and only a
counter PR should attempt to address the veto issue.
Andy.
On 10 July 2017 at 04:12, David Blevins <da...@gmail.com> wrote:
> We’d encourage everyone to vote, but it would be only committers who have
> binding votes.
>
> On your offline feedback about the “Immediate 3 +1s and no -1s” option, I
> had added that in hopes that would “sell” the idea and make RTC more
> palatable. It would addresses the “it will slow us down” issue.
>
> What could we do to refine the idea? Throwing out some options, but let
> me know if you see others:
>
> Option 1: reduce the votes required
>
> - Immediate 2 +1 votes from committers on the project with no
> outstanding -1 votes and no ongoing discussion. No 72 hour vote
> period is required to intentionally to encourage obtaining speed
> throught active list participation.
>
> Option 2: add a slight delay
>
> - 3 +1 votes from committers on the project with no outstanding -1
> votes and no ongoing discussion. 24 hour vote period is required
> to ensure space for minimum participation.
>
> Option 3: both option 1 and 2
>
> - 2 +1 votes from committers on the project with no outstanding -1
> votes and no ongoing discussion. 24 hour vote period is required
> to ensure space for minimum participation.
>
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
> > On Jul 9, 2017, at 1:40 AM, Mark Struberg <st...@yahoo.de.INVALID>
> wrote:
> >
> > Who would have a vote? PMCs only? Active Committers only? Everyone?
> >
> >
> > LieGrue,
> > strub
> >
> >> Am 09.07.2017 um 03:11 schrieb David Blevins <da...@gmail.com>:
> >>
> >> Ok, how would this look as a proposal? Note this is not a vote, we are
> still in discussion. Do suggest changes.
> >>
> >> Whatever we come up with, I’ll swing it by the Board before we vote so
> we don’t feel we need to argue the rules.
> >>
> >> Let’s focus primarily on what we want to do.
> >>
> >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> >>
> >> # Discussion Before Action
> >>
> >> - New features
> >> - Significant changes
> >> - Backwards incompatable changes
> >>
> >> To avoid excessive vetos in the RTC process, discussion prior to
> >> coding is encouraged for the above situations.
> >>
> >> # RTC with Lazy Consensus
> >>
> >> Changes should occur in a fork on Github. A Github Pull Requests (PR)
> >> should be submitted to the dev list for review. The email to the dev
> >> list should stand on its own and use a descriptive subject and contain
> >> a complete description in the body. The body must contain a link to
> >> the PR. The following is an example of an acceptable dev list PR
> >> submission:
> >>
> >> Subject: [PR] AutoConfig::firstMatching sorting issue with java 8
> >>
> >> Fix the sorting issue, by removing the sorting operation. We are not
> >> interested in the order of the elements, but only in the smallest
> >> element.
> >>
> >> Two improvements:
> >>
> >> 1. Do not unnecessary allocate a new array list
> >>
> >> 2. Collections.min() is O(n) vs O(nLog(n) for sort() (well without
> >> counting indexOf() in the comparator)
> >>
> >> https://github.com/apache/tomee/pull/84
> >>
> >> The following email subjects should be discouraged as they drive
> >> discussion off of the list from the very start.
> >>
> >> Subject: [PR] https://github.com/apache/tomee/pull/84
> >> Subject: [PR] #84
> >> Subject: [PR] https://issues.apache.org/jira/browse/TOMEE-2085
> >> Subject: [PR] TOMEE-2085
> >> Subject: [PR] Fixed TOMEE-2085
> >>
> >> PR numbers and JIRA ids are allowed in the subject, but cannot be the
> >> subject exclussively. PR numbers and JIRA ids are allowed in the body,
> >> but cannot be the body exclussively.
> >>
> >> Reviewers are not required to read the Gitub Comments nor the JIRA
> >> Comments. The dev list is considered the only mandatory source of
> >> truth. Answers of "read my comment in the PR" or "read my comment in
> >> the JIRA" are not acceptable means to veto or vote in a code review.
> >> Vetos that cannot be resolved without reading comments off the dev
> >> list are non-binding.
> >>
> >> A PR submitted to the dev list is considered approved if any of the
> >> two conditions are met:
> >>
> >> - Immediate 3 +1 votes from committers on the project with no
> >> outstanding -1 votes and no ongoing discussion. No 72 hour vote
> >> period is required to intentionally to encourage obtaining speed
> >> throught active list participation.
> >>
> >> - Lazy 72 hours pass with no outstanding -1 votes and no ongoing
> >> discussion.
> >>
> >> A committer cannot vote on his or her own PR. A 24 hour warning
> >> email, "I will commit this tomorrow if no one objects" is considered
> >> best practice for larger changes.
> >>
> >
>
>
--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
Re: [Discuss] Review-than-commit 3 month trial
Posted by David Blevins <da...@gmail.com>.
We’d encourage everyone to vote, but it would be only committers who have binding votes.
On your offline feedback about the “Immediate 3 +1s and no -1s” option, I had added that in hopes that would “sell” the idea and make RTC more palatable. It would addresses the “it will slow us down” issue.
What could we do to refine the idea? Throwing out some options, but let me know if you see others:
Option 1: reduce the votes required
- Immediate 2 +1 votes from committers on the project with no
outstanding -1 votes and no ongoing discussion. No 72 hour vote
period is required to intentionally to encourage obtaining speed
throught active list participation.
Option 2: add a slight delay
- 3 +1 votes from committers on the project with no outstanding -1
votes and no ongoing discussion. 24 hour vote period is required
to ensure space for minimum participation.
Option 3: both option 1 and 2
- 2 +1 votes from committers on the project with no outstanding -1
votes and no ongoing discussion. 24 hour vote period is required
to ensure space for minimum participation.
--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
> On Jul 9, 2017, at 1:40 AM, Mark Struberg <st...@yahoo.de.INVALID> wrote:
>
> Who would have a vote? PMCs only? Active Committers only? Everyone?
>
>
> LieGrue,
> strub
>
>> Am 09.07.2017 um 03:11 schrieb David Blevins <da...@gmail.com>:
>>
>> Ok, how would this look as a proposal? Note this is not a vote, we are still in discussion. Do suggest changes.
>>
>> Whatever we come up with, I’ll swing it by the Board before we vote so we don’t feel we need to argue the rules.
>>
>> Let’s focus primarily on what we want to do.
>>
>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>>
>> # Discussion Before Action
>>
>> - New features
>> - Significant changes
>> - Backwards incompatable changes
>>
>> To avoid excessive vetos in the RTC process, discussion prior to
>> coding is encouraged for the above situations.
>>
>> # RTC with Lazy Consensus
>>
>> Changes should occur in a fork on Github. A Github Pull Requests (PR)
>> should be submitted to the dev list for review. The email to the dev
>> list should stand on its own and use a descriptive subject and contain
>> a complete description in the body. The body must contain a link to
>> the PR. The following is an example of an acceptable dev list PR
>> submission:
>>
>> Subject: [PR] AutoConfig::firstMatching sorting issue with java 8
>>
>> Fix the sorting issue, by removing the sorting operation. We are not
>> interested in the order of the elements, but only in the smallest
>> element.
>>
>> Two improvements:
>>
>> 1. Do not unnecessary allocate a new array list
>>
>> 2. Collections.min() is O(n) vs O(nLog(n) for sort() (well without
>> counting indexOf() in the comparator)
>>
>> https://github.com/apache/tomee/pull/84
>>
>> The following email subjects should be discouraged as they drive
>> discussion off of the list from the very start.
>>
>> Subject: [PR] https://github.com/apache/tomee/pull/84
>> Subject: [PR] #84
>> Subject: [PR] https://issues.apache.org/jira/browse/TOMEE-2085
>> Subject: [PR] TOMEE-2085
>> Subject: [PR] Fixed TOMEE-2085
>>
>> PR numbers and JIRA ids are allowed in the subject, but cannot be the
>> subject exclussively. PR numbers and JIRA ids are allowed in the body,
>> but cannot be the body exclussively.
>>
>> Reviewers are not required to read the Gitub Comments nor the JIRA
>> Comments. The dev list is considered the only mandatory source of
>> truth. Answers of "read my comment in the PR" or "read my comment in
>> the JIRA" are not acceptable means to veto or vote in a code review.
>> Vetos that cannot be resolved without reading comments off the dev
>> list are non-binding.
>>
>> A PR submitted to the dev list is considered approved if any of the
>> two conditions are met:
>>
>> - Immediate 3 +1 votes from committers on the project with no
>> outstanding -1 votes and no ongoing discussion. No 72 hour vote
>> period is required to intentionally to encourage obtaining speed
>> throught active list participation.
>>
>> - Lazy 72 hours pass with no outstanding -1 votes and no ongoing
>> discussion.
>>
>> A committer cannot vote on his or her own PR. A 24 hour warning
>> email, "I will commit this tomorrow if no one objects" is considered
>> best practice for larger changes.
>>
>
Re: [Discuss] Review-than-commit 3 month trial
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
Who would have a vote? PMCs only? Active Committers only? Everyone?
LieGrue,
strub
> Am 09.07.2017 um 03:11 schrieb David Blevins <da...@gmail.com>:
>
> Ok, how would this look as a proposal? Note this is not a vote, we are still in discussion. Do suggest changes.
>
> Whatever we come up with, I’ll swing it by the Board before we vote so we don’t feel we need to argue the rules.
>
> Let’s focus primarily on what we want to do.
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
> # Discussion Before Action
>
> - New features
> - Significant changes
> - Backwards incompatable changes
>
> To avoid excessive vetos in the RTC process, discussion prior to
> coding is encouraged for the above situations.
>
> # RTC with Lazy Consensus
>
> Changes should occur in a fork on Github. A Github Pull Requests (PR)
> should be submitted to the dev list for review. The email to the dev
> list should stand on its own and use a descriptive subject and contain
> a complete description in the body. The body must contain a link to
> the PR. The following is an example of an acceptable dev list PR
> submission:
>
> Subject: [PR] AutoConfig::firstMatching sorting issue with java 8
>
> Fix the sorting issue, by removing the sorting operation. We are not
> interested in the order of the elements, but only in the smallest
> element.
>
> Two improvements:
>
> 1. Do not unnecessary allocate a new array list
>
> 2. Collections.min() is O(n) vs O(nLog(n) for sort() (well without
> counting indexOf() in the comparator)
>
> https://github.com/apache/tomee/pull/84
>
> The following email subjects should be discouraged as they drive
> discussion off of the list from the very start.
>
> Subject: [PR] https://github.com/apache/tomee/pull/84
> Subject: [PR] #84
> Subject: [PR] https://issues.apache.org/jira/browse/TOMEE-2085
> Subject: [PR] TOMEE-2085
> Subject: [PR] Fixed TOMEE-2085
>
> PR numbers and JIRA ids are allowed in the subject, but cannot be the
> subject exclussively. PR numbers and JIRA ids are allowed in the body,
> but cannot be the body exclussively.
>
> Reviewers are not required to read the Gitub Comments nor the JIRA
> Comments. The dev list is considered the only mandatory source of
> truth. Answers of "read my comment in the PR" or "read my comment in
> the JIRA" are not acceptable means to veto or vote in a code review.
> Vetos that cannot be resolved without reading comments off the dev
> list are non-binding.
>
> A PR submitted to the dev list is considered approved if any of the
> two conditions are met:
>
> - Immediate 3 +1 votes from committers on the project with no
> outstanding -1 votes and no ongoing discussion. No 72 hour vote
> period is required to intentionally to encourage obtaining speed
> throught active list participation.
>
> - Lazy 72 hours pass with no outstanding -1 votes and no ongoing
> discussion.
>
> A committer cannot vote on his or her own PR. A 24 hour warning
> email, "I will commit this tomorrow if no one objects" is considered
> best practice for larger changes.
>
Re: [Discuss] Review-than-commit 3 month trial
Posted by David Blevins <da...@gmail.com>.
Ok, how would this look as a proposal? Note this is not a vote, we are still in discussion. Do suggest changes.
Whatever we come up with, I’ll swing it by the Board before we vote so we don’t feel we need to argue the rules.
Let’s focus primarily on what we want to do.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# Discussion Before Action
- New features
- Significant changes
- Backwards incompatable changes
To avoid excessive vetos in the RTC process, discussion prior to
coding is encouraged for the above situations.
# RTC with Lazy Consensus
Changes should occur in a fork on Github. A Github Pull Requests (PR)
should be submitted to the dev list for review. The email to the dev
list should stand on its own and use a descriptive subject and contain
a complete description in the body. The body must contain a link to
the PR. The following is an example of an acceptable dev list PR
submission:
Subject: [PR] AutoConfig::firstMatching sorting issue with java 8
Fix the sorting issue, by removing the sorting operation. We are not
interested in the order of the elements, but only in the smallest
element.
Two improvements:
1. Do not unnecessary allocate a new array list
2. Collections.min() is O(n) vs O(nLog(n) for sort() (well without
counting indexOf() in the comparator)
https://github.com/apache/tomee/pull/84
The following email subjects should be discouraged as they drive
discussion off of the list from the very start.
Subject: [PR] https://github.com/apache/tomee/pull/84
Subject: [PR] #84
Subject: [PR] https://issues.apache.org/jira/browse/TOMEE-2085
Subject: [PR] TOMEE-2085
Subject: [PR] Fixed TOMEE-2085
PR numbers and JIRA ids are allowed in the subject, but cannot be the
subject exclussively. PR numbers and JIRA ids are allowed in the body,
but cannot be the body exclussively.
Reviewers are not required to read the Gitub Comments nor the JIRA
Comments. The dev list is considered the only mandatory source of
truth. Answers of "read my comment in the PR" or "read my comment in
the JIRA" are not acceptable means to veto or vote in a code review.
Vetos that cannot be resolved without reading comments off the dev
list are non-binding.
A PR submitted to the dev list is considered approved if any of the
two conditions are met:
- Immediate 3 +1 votes from committers on the project with no
outstanding -1 votes and no ongoing discussion. No 72 hour vote
period is required to intentionally to encourage obtaining speed
throught active list participation.
- Lazy 72 hours pass with no outstanding -1 votes and no ongoing
discussion.
A committer cannot vote on his or her own PR. A 24 hour warning
email, "I will commit this tomorrow if no one objects" is considered
best practice for larger changes.
Re: [Discuss] Review-than-commit 3 month trial
Posted by David Blevins <da...@gmail.com>.
To my tentative counting there seems to be 3 against, 4 pro and a +0. There will definitely be a vote.
If one of the “pros” can start drafting a short doc on how we’d like to do RTC, that’d be awesome. Doesn’t have to be fancy, just something to prevent everyone from interpreting RTC differently. I agree with others who have voiced it that we’d want reviews to be on the dev list.
--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
> On Jul 2, 2017, at 6:04 PM, David Blevins <da...@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.
>
> 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.
>
> - Should all reviews be on the dev list? With Github PRs comments
> and JIRA comments, there needs to be a source of truth.
>
> - Should we fully document the process before we try so we can get
> the most value from a 3 month trial?
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>