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 <agumbre...@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 <strub...@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 <agumbre...@tomitribe.com >>> : >>> >>> There's no 72h waiting period? Just 3+1 to commit. I'd even be for a 2+1. >>> >>> As soon as whatever is decided is counted then the commit occurs. That >>> could be within a few minutes. >>> >>> Andy. >>> >>> On 7 July 2017 at 14:59, Mark Struberg <strub...@yahoo.de.invalid> >> wrote: >>> >>>> +1 well said, Jeff! >>>> >>>> LieGrue, >>>> strub >>>> >>>>> Am 06.07.2017 um 18:37 schrieb Jeff Genender <jgenen...@apache.org>: >>>>> >>>>> Lurking on this, I have to underscore what Mark said. >>>>> >>>>> Andy, you are pretty correct on nearly every point that you made. But >>>> the things stated are more of refining your current process rather than >>>> taking RTC for current committers. You already had RTC with PRs from >>>> outsiders. If that slipped in, it just means that a trusted committer >>>> didn’t do their job. It happens. Breaking a trunk build for a day (or >>>> even a week) is ok. Thats why its trunk. I cannot tell you how many >> times >>>> I have downloaded a project’s trunk and things weren’t quite right. >>>>> >>>>> Relative to what prompted this RTC discussion again, I think things got >>>> emotional and people slipped up afterwards. The beauty of all this is >> all >>>> parties shook hands and made up. Problem was more-or-less solved and >> the >>>> project was back on track. >>>>> >>>>> IMHO, taking on RTC is punitive. It means that you need to reset the >>>> way you do things because you cannot do it yourselves. Do you think you >>>> are at that point? It didn’t look that way to me… but its certainly >>>> possible based on what is being done behind the scenes. >>>>> >>>>> Just some food for thought. >>>>> >>>>> Jeff >>>>> >>>>> >>>>> >>>>>> On Jul 5, 2017, at 7:49 PM, Andy Gumbrecht <agumbre...@tomitribe.com> >>>> wrote: >>>>>> >>>>>> The main issue here is that both new and existing developers on the >>>> project >>>>>> need breathing space in order to thrive and grow. >>>>>> >>>>>> The period between releases is for everyone and not just the few. It >> is >>>>>> only 99.99% OK for one or two individuals. Everyone else seems to be >>>>>> suffering behind closed doors or in silence, or fighting constant >>>> mobbing >>>>>> to the point where 'our' fun project has become too tedious for many >>>>>> people's free time. >>>>>> >>>>>> I'm not going to focus on the reasons behind the "Suffocating >>>> development >>>>>> environment" thread, only that it was the web 'staging' environment >> used >>>>>> for a review, but treated like it was North Korea production nuclear >>>> bomb >>>>>> code. It should have been handled better. We found a resolution the >> long >>>>>> way round (github web hosting). >>>>>> >>>>>> However, the situation has evolved where existing committers don't >>>> discuss, >>>>>> create or assign tickets because they are literally mobbed or hijacked >>>> by >>>>>> another committer within minutes. >>>>>> That is currently so predictable that it has become a kind of un-funny >>>> joke >>>>>> even outside of our community. Tickets are often created 'after' a >>>> commit >>>>>> with a closed status. >>>>>> >>>>>> What needs to change is: >>>>>> >>>>>> Committers need to be able to take and work on a ticket in peace over >>>>>> several days or even weeks, without being trumped due to impatience or >>>> the >>>>>> notion of 'I know better'. >>>>>> Many can only dedicate a finite amount of time, but still need to push >>>>>> in-progress work regularly - Git makes that easier now. The review >>>> process >>>>>> should be a fun and helpful thing. >>>>>> >>>>>> Committers and new contributors should be encouraged to take tickets. >>>>>> >>>>>> At most, impatience should be directed towards discussion, motivation >>>> and >>>>>> encouragement - It's about team play on a global scale, not 'My way or >>>> the >>>>>> highway'. >>>>>> >>>>>> It is often not viable to test the whole project for a small change - >> It >>>>>> takes well over two hours. The buildbot is like our buzzer that says >>>> "fix >>>>>> me" - Not revert me, or trash me, or trump me. >>>>>> >>>>>> Note to self: Why does the word 'trump' feel like it's been hijacked >> by >>>>>> someone?... >>>>>> >>>>>> The 'buzzer' should be allowed to ring for a day or two, again not >>>> everyone >>>>>> stays up the whole night ready to trash a breaking commit. They go to >>>>>> sleep, get up, go to work, get home, eat... and then check the build >> if >>>>>> they have time the next day. >>>>>> >>>>>> It is OK to break the build. Everyone gets to have a go at that and >>>> learn >>>>>> from it. Over and over. We don't release broken builds, only the good >>>> ones >>>>>> in-between. >>>>>> >>>>>> Any disagreement at any level goes to a vote. The majority wins. >>>>>> >>>>>> I think a trial RTC policy can help achieve these goals as it forces >>>>>> community involvement - A good thing. >>>>>> >>>>>> Andy. >>>>>> >>>>>> >>>>>> >>>>>> On 5 July 2017 at 23:02, Jonathan Gallimore < >>>> jonathan.gallim...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Are you referring to the changes in the "Suffocating development >>>>>>> environment" thread, or something else? In my view, the patch Andy >>>> applied >>>>>>> last week had very limited review (1 person), and the revert had no >>>> review. >>>>>>> We've seen contributions come in through GitHub PRs (which is great), >>>> but >>>>>>> also applied directly to the repository by committers without further >>>>>>> discussion (less great), effectively meaning just 1 reviewer - I'm >> not >>>> sure >>>>>>> that's really the spirit of RTC. >>>>>>> >>>>>>> Jon >>>>>>> >>>>>>> >>>>>>> On Wed, Jul 5, 2017 at 6:06 PM, Mark Struberg >>>> <strub...@yahoo.de.invalid> >>>>>>> wrote: >>>>>>> >>>>>>>> As far as I recall the original issue was initially caused by >>>> applying a >>>>>>>> PR. >>>>>>>> That means we had this very issue with a commit which had RTC in >>>> place. >>>>>>>> >>>>>>>> Draw your own conclusions... >>>>>>>> >>>>>>>> LieGrue, >>>>>>>> strub >>>>>>>> >>>>>>>> >>>>>>>>> Am 05.07.2017 um 14:26 schrieb Romain Manni-Bucau < >>>>>>> rmannibu...@gmail.com >>>>>>>>> : >>>>>>>>> >>>>>>>>> Hmm, let put it in a raw way: can we skip the asf list on these >>>>>>>>> discussions? Literally means can be use the way everybody uses for >>>> RTC, >>>>>>>> ie >>>>>>>>> github PRs *only*. If not I don't see the point to use it since >>>>>>>>> contributors we got are mainly github/jira and I think it is >> natural >>>>>>> as a >>>>>>>>> contributor to use these media instead of the list. >>>>>>>>> >>>>>>>>> Can we somehow merge the github flow with the mailing in a smoother >>>> way >>>>>>>>> than the jira integration - and even make jira optional? If not I'm >>>>>>>> pretty >>>>>>>>> sure it doesn't need any more evaluation, if we can then it can be >>>>>>> great >>>>>>>> to >>>>>>>>> benefit from github well known flow. >>>>>>>>> >>>>>>>>> To rephrase it to maybe make it even more explicit: it is not about >>>>>>>> making >>>>>>>>> our - as committers - work easier but making contributions easier. >>>>>>>>> >>>>>>>>> >>>>>>>>> Romain Manni-Bucau >>>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>>>>>>>> <https://blog-rmannibucau.rhcloud.com> | Old Blog >>>>>>>>> <http://rmannibucau.wordpress.com> | Github < >>>>>>>> https://github.com/rmannibucau> | >>>>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE >> Factory >>>>>>>>> <https://javaeefactory-rmannibucau.rhcloud.com> >>>>>>>>> >>>>>>>>> 2017-07-05 13:23 GMT+02:00 Jonathan Gallimore < >>>>>>>> jonathan.gallim...@gmail.com> >>>>>>>>> : >>>>>>>>> >>>>>>>>>> As I see it, while the recent issue with the documentation was >>>>>>> probably >>>>>>>> the >>>>>>>>>> trigger for discussing RTC on dev@, I think the general idea is >>>>>>>> actually >>>>>>>>>> to >>>>>>>>>> get more discussion going on around features and fixes, and to >>>>>>> encourage >>>>>>>>>> more interaction in the review process. We are struggling as a >>>>>>>> community in >>>>>>>>>> that regard. The documentation issue might now be "fixed" by using >>>>>>>> personal >>>>>>>>>> html area usage, but I still think RTC is worthy of consideration. >>>> We >>>>>>>> are >>>>>>>>>> seeing some contributions come in from new contributors and we >> have >>>> an >>>>>>>>>> opportunity to nurture them through this discussion and review >>>>>>> process. >>>>>>>>>> >>>>>>>>>> Incidentally, if we trialled RTC and saw improvements, I'd vote to >>>>>>> keep >>>>>>>> it >>>>>>>>>> after 3 months and not "safely return back". If we don't see >>>>>>>> improvements, >>>>>>>>>> I'd be trying to think of some other ideas to try. I think we'd >> all >>>> be >>>>>>>> open >>>>>>>>>> to other suggestions as well, but I'm of the view that if we don't >>>> try >>>>>>>>>> something, then potentially nothing will change. >>>>>>>>>> >>>>>>>>>> Jon >>>>>>>>>> >>>>>>>>>> On Wed, Jul 5, 2017 at 9:25 AM, Romain Manni-Bucau < >>>>>>>> rmannibu...@gmail.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> 2017-07-05 10:00 GMT+02:00 Gurkan Erdogdu < >> gurkanerdo...@yahoo.com >>>> . >>>>>>>>>>> invalid>: >>>>>>>>>>> >>>>>>>>>>>> Romain>>>>@Gurkan: concretely nothing changed factually since we >>>>>>>>>>> discussed >>>>>>>>>>>> it and concluded we can't pay the overhead at the moment so why >>>>>>>> pushing >>>>>>>>>>>> it?I looked at the commit history from github ( >>>>>>>>>>> https://github.com/apache/ >>>>>>>>>>>> tomee/graphs/contributors). Only some couple of members provide >>>>>>>>>>>> contributions in last couple of years. We need a more >>>> stable/healthy >>>>>>>>>>>> community to increase the chance of long living the project. You >>>> are >>>>>>>>>>> wrong, >>>>>>>>>>>> the reason behind the such discussion is not related with prod, >>>>>>>> website >>>>>>>>>>> or >>>>>>>>>>>> project source code. We are looking for some alternative >> solution >>>>>>> (at >>>>>>>>>>> least >>>>>>>>>>>> temporarily) because of the mentioned problems. I suspect that >>>> this >>>>>>>>>> type >>>>>>>>>>> of >>>>>>>>>>>> conflicts may occur in the future again. I am pushing this for >> the >>>>>>>>>>> success >>>>>>>>>>>> and future of Apache TomEE. I am not a PMC member or committer >> of >>>>>>>> TomEE >>>>>>>>>>>> project, but I just wanted to give my comments as ASF member. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Don't think so Gurkan, the problem was really bound to end user >>>>>>> direct >>>>>>>>>>> impact and we tackled it with the personal html area usage we >> need >>>> to >>>>>>>>>>> document now. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Regards.Gurkan- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Wednesday, July 5, 2017, 10:13:22 AM GMT+3, Romain >> Manni-Bucau >>>> < >>>>>>>>>>>> rmannibu...@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> @Gurkan: concretely nothing changed factually since we discussed >>>> it >>>>>>>> and >>>>>>>>>>>> concluded we can't pay the overhead at the moment so why pushing >>>> it? >>>>>>>>>>>> Concretely the issue was very particular in term of process >> cause >>>>>>>>>>> affecting >>>>>>>>>>>> almost directly our "prod" versus our project source doesn't and >>>> we >>>>>>>> can >>>>>>>>>>>> therefore tolerate more latency. And side note (probably some >>>>>>> wording >>>>>>>>>>> issue >>>>>>>>>>>> but just to make it obvious if not): if it is to go back to the >>>>>>> normal >>>>>>>>>>>> process anyway after then we can gain these 3 months and already >>>>>>> work >>>>>>>>>> as >>>>>>>>>>> we >>>>>>>>>>>> and we'll do ;). >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>>>>>>>>>>> <https://blog-rmannibucau.rhcloud.com> | Old Blog >>>>>>>>>>>> <http://rmannibucau.wordpress.com> | Github < >> https://github.com/ >>>>>>>>>>>> rmannibucau> | >>>>>>>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE >>>> Factory >>>>>>>>>>>> <https://javaeefactory-rmannibucau.rhcloud.com> >>>>>>>>>>>> >>>>>>>>>>>> 2017-07-05 7:28 GMT+02:00 Gurkan Erdogdu < >> gurkanerdo...@yahoo.com >>>> . >>>>>>>>>>>> invalid>: >>>>>>>>>>>> >>>>>>>>>>>>> Hi MarkThis is only for fixing the appeared (very important) >>>>>>> problem >>>>>>>>>> in >>>>>>>>>>>>> the community. So, I don't see what will happen to the project >>>> in 3 >>>>>>>>>>>> months >>>>>>>>>>>>> period with RTC process? So, at least 3 months, every commit >> will >>>>>>> be >>>>>>>>>>>>> approved by the community via consensus. After that, we can >>>> safely >>>>>>>>>>> return >>>>>>>>>>>>> back to the normal process. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks.Gurkan >>>>>>>>>>>>> On Wednesday, July 5, 2017, 1:15:31 AM GMT+3, Mark Struberg >>>>>>>>>>>>> <strub...@yahoo.de.INVALID> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> RTC in my experience _only_ works on release branches, but is a >>>>>>> total >>>>>>>>>>>>> community killer on the mainstream branch (master, dev, >> whatever >>>>>>> you >>>>>>>>>>> call >>>>>>>>>>>>> it). >>>>>>>>>>>>> >>>>>>>>>>>>> We usually don't have so many concurrent commits on the same >>>> topic. >>>>>>>>>>> There >>>>>>>>>>>>> was recently an exceptional case and it got resolved. >>>>>>>>>>>>> Thus -1 >>>>>>>>>>>>> >>>>>>>>>>>>> Of course discussions might be done first. But not via PR but >> via >>>>>>>>>> mail. >>>>>>>>>>>>> Usually the devs have a good feeling about what is sensible and >>>>>>> what >>>>>>>>>>> not. >>>>>>>>>>>>> For some deep change one usually sends a patch first for >> review. >>>>>>> That >>>>>>>>>>> is >>>>>>>>>>>>> nothing we need to enforce - every good programmer will do just >>>>>>> that! >>>>>>>>>>>>> Otoh there are 99.99% of stuff which you just get done and >> commit >>>>>>> it. >>>>>>>>>>> And >>>>>>>>>>>>> if there is something fishy, then it get's caught via the >> commit >>>>>>> log >>>>>>>>>>>> mails >>>>>>>>>>>>> anyway. >>>>>>>>>>>>> >>>>>>>>>>>>> LieGrue, >>>>>>>>>>>>> strub >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Am 03.07.2017 um 10:05 schrieb Jonathan Gallimore < >>>>>>>>>>>>> jonathan.gallim...@gmail.com>: >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, Jul 3, 2017 at 2:04 AM, David Blevins < >>>>>>>>>>> david.blev...@gmail.com >>>>>>>>>>>>> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> There’s a discussion on the private list on this topic, but >>>> given >>>>>>>>>>> the >>>>>>>>>>>>>>> recent thread I think it makes sense to move that here. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The vote would be only on this question: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - Is RTC worth trying for 3 months? (+1,+/-0,-1) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I’ve seen some voices in favor, but do not want to propose a >>>> vote >>>>>>>>>>>>>>> without a heads-up. Specifically, even if many people like >> the >>>>>>>>>> idea >>>>>>>>>>>>>>> we should talk about how we want to do it. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> # Review-than-commit >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> For those that do not know, Review-than-commit is essentially >>>>>>> what >>>>>>>>>>>>>>> Github Pull Requests are. Prior to github, Apache describes >>>> them >>>>>>>>>>> as: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - Commit policy which requires that all changes receive >>>> consensus >>>>>>>>>>>>>>> approval in order to be committed. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think we’ve seen evidence that: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - Slowing ourselves down can be a good thing. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - Moving ahead after discussion is a good thing. Discussion >>>>>>>>>> should >>>>>>>>>>>>>>> precede even the first commit. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - More eyes and talk around commits can help documentation >>>>>>>>>> efforts. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - As 3 +1s are required, a one-to-one conversation with no >> one >>>>>>>>>> else >>>>>>>>>>>>>>> included is naturally discouraged. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> # Trial basis >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> My thought is to go RTC for 3 months as a trial. After 3 >>>> months, >>>>>>>>>> no >>>>>>>>>>>>>>> action means we revert back to our present CTR. A new vote >>>> would >>>>>>>>>> be >>>>>>>>>>>>>>> required to continue RTC in any form, as-was or modified. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Unless its obviously unanimous that everyone dislikes RTC at >> the >>>>>>>>>> end >>>>>>>>>>>> of 3 >>>>>>>>>>>>>> months, I'd suggest we call a vote to decide how to proceed. >> Not >>>>>>>>>>> quite >>>>>>>>>>>>> sure >>>>>>>>>>>>>> how that fits into +1/0/-1 however, so may be it should be a 3 >>>>>>>>>> month >>>>>>>>>>>>> trial, >>>>>>>>>>>>>> followed by 2 weeks for review and discussion (during which >> we'd >>>>>>>>>>> still >>>>>>>>>>>> be >>>>>>>>>>>>>> RTC) and then a vote? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The trial-basis is to acknowledge that we are voting on a >> guess >>>>>>> of >>>>>>>>>>>>>>> potential benefits. This allows us to "try before we buy" >> and >>>>>>> the >>>>>>>>>>>>>>> vote really comes down to if we want to try. We need not >> make >>>> a >>>>>>>>>>>>>>> decision based on other people's experience and have a means >> to >>>>>>>>>> gain >>>>>>>>>>>>>>> our own experience with a built-in escape clause that >> triggers >>>>>>>>>>> lazily. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> RTC may sound like a good idea, but our implemention of it >> may >>>> be >>>>>>>>>>> bad >>>>>>>>>>>>>>> in practise. It may sound like a bad idea, but we may >> discover >>>>>>>>>>>>>>> positives we hadn't anticipated. We don't currently know. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> # How would we do it? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Some things that would be good to discuss: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - How could we use github pull requests? Other communities >> do >>>>>>>>>> use >>>>>>>>>>>>>>> them and I suspect there are options we have not explored. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'd be in favour of that, as that process seems to be very >> well >>>>>>>>>>> known. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - Should all reviews be on the dev list? With Github PRs >>>> comments >>>>>>>>>>>>>>> and JIRA comments, there needs to be a source of truth. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think both the discussion and review should happen on the >> dev >>>>>>>>>> list. >>>>>>>>>>>>>> GH/JIRA comments are fine in themselves, but there may be >>>> (should >>>>>>>>>> be) >>>>>>>>>>>>>> discussion on dev@ before a PR is opened, so having all that >>>>>>>>>>>> discussion >>>>>>>>>>>>> in >>>>>>>>>>>>>> one place is important for me. Even if GH comments prove >>>> popular, >>>>>>>>>> its >>>>>>>>>>>> not >>>>>>>>>>>>>> hard to copy/paste it to dev@ with a link. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - Should we fully document the process before we try so we >> can >>>>>>>>>> get >>>>>>>>>>>>>>> the most value from a 3 month trial? >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'd be in favour of discussing and documenting. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> David Blevins >>>>>>>>>>>>>>> http://twitter.com/dblevins >>>>>>>>>>>>>>> http://www.tomitribe.com >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Andy Gumbrecht >>>>>> https://twitter.com/AndyGeeDe >>>>>> http://www.tomitribe.com >>>>> >>>> >>>> >>> >>> >>> -- >>> Andy Gumbrecht >>> https://twitter.com/AndyGeeDe >>> http://www.tomitribe.com >> >> > > > -- > Andy Gumbrecht > https://twitter.com/AndyGeeDe > http://www.tomitribe.com
