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 <agumbre...@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 <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 > -- Andy Gumbrecht https://twitter.com/AndyGeeDe http://www.tomitribe.com
