You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Konstantin Boudnik <co...@apache.org> on 2015/10/01 00:52:08 UTC
Re: Let's please fix the mess in Git
On Wed, Sep 30, 2015 at 09:32PM, Raul Kripalani wrote:
> Igniters,
>
> 1. Git history is polluted by lots of commits like: "Merge remote-tracking
> branch 'origin/ignite-1.4' into ignite-1.4". Is there a logical reason for
> this? Why doesn't the team use git pull --rebase?
>
> 2. Let's please define a policy for Git commit messages. The current Git
> history is an *utter mess*. This is totally unacceptable on master:
> https://imgur.com/I95TPMd.
>
> a. Commit messages must carry a context. You should not oblige your
> fellows to dig into the diff to understand what you've done.
>
> b. Even if you are referencing a JIRA ticket, please include some
> context. Nobody remembers ticket numbers by heart and it's a waste of time
> to open a browser tab for every commit.
>
> c. Pasting the full JIRA URL is wasteful and uses precious real estate.
> Everybody knows that if you refer to IGNITE-nnnn, you're referring to an
> ASF JIRA ticket.
>
> I agree with many of the tips on this post about Git commit message best
> practices [1]. I suggest you read if you haven't yet.
>
> 3. Let's clarify the merging policy. Yakov complained because I merged a
> branch without squashing. But I see people are doing this. He also
> referenced a Wiki page that explained the procedure for Github pull
> requests. Are we allowed to merge internal branches without squashing?
We shouldn't be. We had this lengthy discussion about proper git practices
where it has been established that squashing of intermediate commits is a
blessing because
a) no one is interested in "Oh, heck - I forgot the letter" commits
b) rebase-then-merge allows to avoid meaningless "Merge commits", which might
only be valuable for bring in some big feature branches, etc.
Good points on the rest of it as well - let's have some discipline around
this.
Cos
>
> [1] http://chris.beams.io/posts/git-commit/
>
> Regards,
>
> *Raúl Kripalani*
> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
> Messaging Engineer
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> http://blog.raulkr.net | twitter: @raulvk
Re: Let's please fix the mess in Git
Posted by Sergi Vladykin <se...@gmail.com>.
Brane,
2015-10-01 20:31 GMT+03:00 Branko Čibej <br...@apache.org>:
> Stop. Right. There.
>
> If you're going to start pointing fingers at people you can just shut
> down the project because you're going down the road of petty bickering.
> That's a great way to dissolve the community into chaos.
>
>
Of course we must be polite to each other if we want to work together.
I'd suggest Pavel to write personal emails instead of discussing teammates
on the dev list.
>
> On the topic of git usage:
>
> * Raul is absolutely right about commit messages. When you write a
> commit message, think about how useful it would be to *you* if
> someone else were writing it.
>
Agree, moreover I think it is a good idea to use the same description as in
Jira issue and pull request name.
>
> * I find it really ludicrous that committers on this project are going
> through the GitHub pull request rigmarole instead of pushing
> directly to the ASF repository. Surely you're not serious? You're
> forcing others to RTC instead of doing the right thing in the first
> place.
>
For me the right thing is to use convenient and reliable tools with
straightforward
automated work flow to avoid human errors as much as possible. In this
respect git by itself is a wrong tool just because it allows to do a single
thing
multiple ways and now we have to argue which way is "right" or "wrong".
GitHub + apply-pull-request.sh is a right choice for me because it does not
allow
random shit to happen and you always share the responsibility with the
reviewer.
And you are right, I actually prefer to enforce RTC for everyone, because
as far
as I remember CTR was encouraged only for minor changes like javadoc fix
and it was strongly recommended to do a review for more complex
changes, but this strong recommendation is simply ignored right now.
See https://cwiki.apache.org/confluence/display/IGNITE/Jira+Process
>
> * Last but not least: learn to use your tools. The best way to do this
> is for someone who really gets git to write up usage guidelines. The
> "Git Process" page in cwiki is missing quite a few important bits:
> especially actual examples, naming conventions (for tags etc.) and
> so on. Git semantics are fsck'd up enough as it is, it makes no
> sense for every developer to try to figure out the right way by
> herself.
>
Agree that we need to describe naming conventions but everything that
can be automated here must be automated. And we already have done that:
look inside of `scripts` folder.
Sergi
>
> -- Brane
>
>
>
> On 01.10.2015 19:01, Pavel Tupitsyn wrote:
> > Sergi, your point is valid, but you are shifting the point of the
> > discussion.
> >
> > Current master branch history, indeed, looks unacceptable. Mostly due to
> > insufficient commit descriptions from Anton and Semyon.
> >
> > On Thu, Oct 1, 2015 at 7:34 PM, Sergi Vladykin <sergi.vladykin@gmail.com
> >
> > wrote:
> >
> >> Raul,
> >>
> >> First of all I think it is not an excuse that you did bad thing because
> >> others did as well.
> >> Lets try to be perfect ourselves before blaming others.
> >>
> >> Do you know how I lately solve these issues with comments, squashing and
> >> other stuff?
> >> I do not do any merges of *my* changes to master at all. Almost never.
> >> I just provide pull request on GitHub and ask a reviewer to merge it or
> >> return with comments.
> >> And when someone asks me to do the same I just do it using provided
> script
> >> *scripts/apply-pull-request.sh*
> >> There is no chance to do something wrong here.
> >>
> >> I encourage you to do the same and all of your questions will disappear
> in
> >> a second.
> >>
> >> Sergi
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> 2015-10-01 1:52 GMT+03:00 Konstantin Boudnik <co...@apache.org>:
> >>
> >>> On Wed, Sep 30, 2015 at 09:32PM, Raul Kripalani wrote:
> >>>> Igniters,
> >>>>
> >>>> 1. Git history is polluted by lots of commits like: "Merge
> >>> remote-tracking
> >>>> branch 'origin/ignite-1.4' into ignite-1.4". Is there a logical reason
> >>> for
> >>>> this? Why doesn't the team use git pull --rebase?
> >>>>
> >>>> 2. Let's please define a policy for Git commit messages. The current
> >> Git
> >>>> history is an *utter mess*. This is totally unacceptable on master:
> >>>> https://imgur.com/I95TPMd.
> >>>>
> >>>> a. Commit messages must carry a context. You should not oblige your
> >>>> fellows to dig into the diff to understand what you've done.
> >>>>
> >>>> b. Even if you are referencing a JIRA ticket, please include some
> >>>> context. Nobody remembers ticket numbers by heart and it's a waste of
> >>> time
> >>>> to open a browser tab for every commit.
> >>>>
> >>>> c. Pasting the full JIRA URL is wasteful and uses precious real
> >>> estate.
> >>>> Everybody knows that if you refer to IGNITE-nnnn, you're referring to
> >> an
> >>>> ASF JIRA ticket.
> >>>>
> >>>> I agree with many of the tips on this post about Git commit message
> >> best
> >>>> practices [1]. I suggest you read if you haven't yet.
> >>>>
> >>>> 3. Let's clarify the merging policy. Yakov complained because I merged
> >> a
> >>>> branch without squashing. But I see people are doing this. He also
> >>>> referenced a Wiki page that explained the procedure for Github pull
> >>>> requests. Are we allowed to merge internal branches without squashing?
> >>> We shouldn't be. We had this lengthy discussion about proper git
> >> practices
> >>> where it has been established that squashing of intermediate commits
> is
> >> a
> >>> blessing because
> >>> a) no one is interested in "Oh, heck - I forgot the letter" commits
> >>> b) rebase-then-merge allows to avoid meaningless "Merge commits",
> which
> >>> might
> >>> only be valuable for bring in some big feature branches, etc.
> >>>
> >>> Good points on the rest of it as well - let's have some discipline
> around
> >>> this.
> >>>
> >>> Cos
> >>>> [1] http://chris.beams.io/posts/git-commit/
> >>>>
> >>>> Regards,
> >>>>
> >>>> *Raúl Kripalani*
> >>>> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data
> >> and
> >>>> Messaging Engineer
> >>>> http://about.me/raulkripalani |
> >> http://www.linkedin.com/in/raulkripalani
> >>>> http://blog.raulkr.net | twitter: @raulvk
> >
> >
>
>
Re: Let's please fix the mess in Git
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Thu, Oct 1, 2015 at 7:31 PM, Branko Čibej <br...@apache.org> wrote:
> Stop. Right. There.
>
> If you're going to start pointing fingers at people you can just shut
> down the project because you're going down the road of petty bickering.
> That's a great way to dissolve the community into chaos.
>
>
> On the topic of git usage:
>
> * Raul is absolutely right about commit messages. When you write a
> commit message, think about how useful it would be to *you* if
> someone else were writing it.
>
Agree.
>
> * I find it really ludicrous that committers on this project are going
> through the GitHub pull request rigmarole instead of pushing
> directly to the ASF repository. Surely you're not serious? You're
> forcing others to RTC instead of doing the right thing in the first
> place.
>
In my view, CTR is not a religion, but rather a tool to speed up
development on a project. I think we can all agree that it does not always
"speed up" the process.
I personally believe that if a commit is moderately complex, it should be
reviewed by a peer. This has nothing to do with trust, just good
engineering practice.
>
> * Last but not least: learn to use your tools. The best way to do this
> is for someone who really gets git to write up usage guidelines. The
> "Git Process" page in cwiki is missing quite a few important bits:
> especially actual examples, naming conventions (for tags etc.) and
> so on. Git semantics are fsck'd up enough as it is, it makes no
> sense for every developer to try to figure out the right way by
> herself.
>
Very good point. The documentation right now has lots of omissions, we
should fix it.
>
>
> -- Brane
>
>
>
> On 01.10.2015 19:01, Pavel Tupitsyn wrote:
> > Sergi, your point is valid, but you are shifting the point of the
> > discussion.
> >
> > Current master branch history, indeed, looks unacceptable. Mostly due to
> > insufficient commit descriptions from Anton and Semyon.
> >
> > On Thu, Oct 1, 2015 at 7:34 PM, Sergi Vladykin <sergi.vladykin@gmail.com
> >
> > wrote:
> >
> >> Raul,
> >>
> >> First of all I think it is not an excuse that you did bad thing because
> >> others did as well.
> >> Lets try to be perfect ourselves before blaming others.
> >>
> >> Do you know how I lately solve these issues with comments, squashing and
> >> other stuff?
> >> I do not do any merges of *my* changes to master at all. Almost never.
> >> I just provide pull request on GitHub and ask a reviewer to merge it or
> >> return with comments.
> >> And when someone asks me to do the same I just do it using provided
> script
> >> *scripts/apply-pull-request.sh*
> >> There is no chance to do something wrong here.
> >>
> >> I encourage you to do the same and all of your questions will disappear
> in
> >> a second.
> >>
> >> Sergi
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> 2015-10-01 1:52 GMT+03:00 Konstantin Boudnik <co...@apache.org>:
> >>
> >>> On Wed, Sep 30, 2015 at 09:32PM, Raul Kripalani wrote:
> >>>> Igniters,
> >>>>
> >>>> 1. Git history is polluted by lots of commits like: "Merge
> >>> remote-tracking
> >>>> branch 'origin/ignite-1.4' into ignite-1.4". Is there a logical reason
> >>> for
> >>>> this? Why doesn't the team use git pull --rebase?
> >>>>
> >>>> 2. Let's please define a policy for Git commit messages. The current
> >> Git
> >>>> history is an *utter mess*. This is totally unacceptable on master:
> >>>> https://imgur.com/I95TPMd.
> >>>>
> >>>> a. Commit messages must carry a context. You should not oblige your
> >>>> fellows to dig into the diff to understand what you've done.
> >>>>
> >>>> b. Even if you are referencing a JIRA ticket, please include some
> >>>> context. Nobody remembers ticket numbers by heart and it's a waste of
> >>> time
> >>>> to open a browser tab for every commit.
> >>>>
> >>>> c. Pasting the full JIRA URL is wasteful and uses precious real
> >>> estate.
> >>>> Everybody knows that if you refer to IGNITE-nnnn, you're referring to
> >> an
> >>>> ASF JIRA ticket.
> >>>>
> >>>> I agree with many of the tips on this post about Git commit message
> >> best
> >>>> practices [1]. I suggest you read if you haven't yet.
> >>>>
> >>>> 3. Let's clarify the merging policy. Yakov complained because I merged
> >> a
> >>>> branch without squashing. But I see people are doing this. He also
> >>>> referenced a Wiki page that explained the procedure for Github pull
> >>>> requests. Are we allowed to merge internal branches without squashing?
> >>> We shouldn't be. We had this lengthy discussion about proper git
> >> practices
> >>> where it has been established that squashing of intermediate commits
> is
> >> a
> >>> blessing because
> >>> a) no one is interested in "Oh, heck - I forgot the letter" commits
> >>> b) rebase-then-merge allows to avoid meaningless "Merge commits",
> which
> >>> might
> >>> only be valuable for bring in some big feature branches, etc.
> >>>
> >>> Good points on the rest of it as well - let's have some discipline
> around
> >>> this.
> >>>
> >>> Cos
> >>>> [1] http://chris.beams.io/posts/git-commit/
> >>>>
> >>>> Regards,
> >>>>
> >>>> *Raúl Kripalani*
> >>>> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data
> >> and
> >>>> Messaging Engineer
> >>>> http://about.me/raulkripalani |
> >> http://www.linkedin.com/in/raulkripalani
> >>>> http://blog.raulkr.net | twitter: @raulvk
> >
> >
>
>
Re: Let's please fix the mess in Git
Posted by Branko Čibej <br...@apache.org>.
Stop. Right. There.
If you're going to start pointing fingers at people you can just shut
down the project because you're going down the road of petty bickering.
That's a great way to dissolve the community into chaos.
On the topic of git usage:
* Raul is absolutely right about commit messages. When you write a
commit message, think about how useful it would be to *you* if
someone else were writing it.
* I find it really ludicrous that committers on this project are going
through the GitHub pull request rigmarole instead of pushing
directly to the ASF repository. Surely you're not serious? You're
forcing others to RTC instead of doing the right thing in the first
place.
* Last but not least: learn to use your tools. The best way to do this
is for someone who really gets git to write up usage guidelines. The
"Git Process" page in cwiki is missing quite a few important bits:
especially actual examples, naming conventions (for tags etc.) and
so on. Git semantics are fsck'd up enough as it is, it makes no
sense for every developer to try to figure out the right way by herself.
-- Brane
On 01.10.2015 19:01, Pavel Tupitsyn wrote:
> Sergi, your point is valid, but you are shifting the point of the
> discussion.
>
> Current master branch history, indeed, looks unacceptable. Mostly due to
> insufficient commit descriptions from Anton and Semyon.
>
> On Thu, Oct 1, 2015 at 7:34 PM, Sergi Vladykin <se...@gmail.com>
> wrote:
>
>> Raul,
>>
>> First of all I think it is not an excuse that you did bad thing because
>> others did as well.
>> Lets try to be perfect ourselves before blaming others.
>>
>> Do you know how I lately solve these issues with comments, squashing and
>> other stuff?
>> I do not do any merges of *my* changes to master at all. Almost never.
>> I just provide pull request on GitHub and ask a reviewer to merge it or
>> return with comments.
>> And when someone asks me to do the same I just do it using provided script
>> *scripts/apply-pull-request.sh*
>> There is no chance to do something wrong here.
>>
>> I encourage you to do the same and all of your questions will disappear in
>> a second.
>>
>> Sergi
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 2015-10-01 1:52 GMT+03:00 Konstantin Boudnik <co...@apache.org>:
>>
>>> On Wed, Sep 30, 2015 at 09:32PM, Raul Kripalani wrote:
>>>> Igniters,
>>>>
>>>> 1. Git history is polluted by lots of commits like: "Merge
>>> remote-tracking
>>>> branch 'origin/ignite-1.4' into ignite-1.4". Is there a logical reason
>>> for
>>>> this? Why doesn't the team use git pull --rebase?
>>>>
>>>> 2. Let's please define a policy for Git commit messages. The current
>> Git
>>>> history is an *utter mess*. This is totally unacceptable on master:
>>>> https://imgur.com/I95TPMd.
>>>>
>>>> a. Commit messages must carry a context. You should not oblige your
>>>> fellows to dig into the diff to understand what you've done.
>>>>
>>>> b. Even if you are referencing a JIRA ticket, please include some
>>>> context. Nobody remembers ticket numbers by heart and it's a waste of
>>> time
>>>> to open a browser tab for every commit.
>>>>
>>>> c. Pasting the full JIRA URL is wasteful and uses precious real
>>> estate.
>>>> Everybody knows that if you refer to IGNITE-nnnn, you're referring to
>> an
>>>> ASF JIRA ticket.
>>>>
>>>> I agree with many of the tips on this post about Git commit message
>> best
>>>> practices [1]. I suggest you read if you haven't yet.
>>>>
>>>> 3. Let's clarify the merging policy. Yakov complained because I merged
>> a
>>>> branch without squashing. But I see people are doing this. He also
>>>> referenced a Wiki page that explained the procedure for Github pull
>>>> requests. Are we allowed to merge internal branches without squashing?
>>> We shouldn't be. We had this lengthy discussion about proper git
>> practices
>>> where it has been established that squashing of intermediate commits is
>> a
>>> blessing because
>>> a) no one is interested in "Oh, heck - I forgot the letter" commits
>>> b) rebase-then-merge allows to avoid meaningless "Merge commits", which
>>> might
>>> only be valuable for bring in some big feature branches, etc.
>>>
>>> Good points on the rest of it as well - let's have some discipline around
>>> this.
>>>
>>> Cos
>>>> [1] http://chris.beams.io/posts/git-commit/
>>>>
>>>> Regards,
>>>>
>>>> *Raúl Kripalani*
>>>> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data
>> and
>>>> Messaging Engineer
>>>> http://about.me/raulkripalani |
>> http://www.linkedin.com/in/raulkripalani
>>>> http://blog.raulkr.net | twitter: @raulvk
>
>
Re: Let's please fix the mess in Git
Posted by Pavel Tupitsyn <pt...@gridgain.com>.
Sergi, your point is valid, but you are shifting the point of the
discussion.
Current master branch history, indeed, looks unacceptable. Mostly due to
insufficient commit descriptions from Anton and Semyon.
On Thu, Oct 1, 2015 at 7:34 PM, Sergi Vladykin <se...@gmail.com>
wrote:
> Raul,
>
> First of all I think it is not an excuse that you did bad thing because
> others did as well.
> Lets try to be perfect ourselves before blaming others.
>
> Do you know how I lately solve these issues with comments, squashing and
> other stuff?
> I do not do any merges of *my* changes to master at all. Almost never.
> I just provide pull request on GitHub and ask a reviewer to merge it or
> return with comments.
> And when someone asks me to do the same I just do it using provided script
> *scripts/apply-pull-request.sh*
> There is no chance to do something wrong here.
>
> I encourage you to do the same and all of your questions will disappear in
> a second.
>
> Sergi
>
>
>
>
>
>
>
>
>
>
>
> 2015-10-01 1:52 GMT+03:00 Konstantin Boudnik <co...@apache.org>:
>
> > On Wed, Sep 30, 2015 at 09:32PM, Raul Kripalani wrote:
> > > Igniters,
> > >
> > > 1. Git history is polluted by lots of commits like: "Merge
> > remote-tracking
> > > branch 'origin/ignite-1.4' into ignite-1.4". Is there a logical reason
> > for
> > > this? Why doesn't the team use git pull --rebase?
> > >
> > > 2. Let's please define a policy for Git commit messages. The current
> Git
> > > history is an *utter mess*. This is totally unacceptable on master:
> > > https://imgur.com/I95TPMd.
> > >
> > > a. Commit messages must carry a context. You should not oblige your
> > > fellows to dig into the diff to understand what you've done.
> > >
> > > b. Even if you are referencing a JIRA ticket, please include some
> > > context. Nobody remembers ticket numbers by heart and it's a waste of
> > time
> > > to open a browser tab for every commit.
> > >
> > > c. Pasting the full JIRA URL is wasteful and uses precious real
> > estate.
> > > Everybody knows that if you refer to IGNITE-nnnn, you're referring to
> an
> > > ASF JIRA ticket.
> > >
> > > I agree with many of the tips on this post about Git commit message
> best
> > > practices [1]. I suggest you read if you haven't yet.
> > >
> > > 3. Let's clarify the merging policy. Yakov complained because I merged
> a
> > > branch without squashing. But I see people are doing this. He also
> > > referenced a Wiki page that explained the procedure for Github pull
> > > requests. Are we allowed to merge internal branches without squashing?
> >
> > We shouldn't be. We had this lengthy discussion about proper git
> practices
> > where it has been established that squashing of intermediate commits is
> a
> > blessing because
> > a) no one is interested in "Oh, heck - I forgot the letter" commits
> > b) rebase-then-merge allows to avoid meaningless "Merge commits", which
> > might
> > only be valuable for bring in some big feature branches, etc.
> >
> > Good points on the rest of it as well - let's have some discipline around
> > this.
> >
> > Cos
> > >
> > > [1] http://chris.beams.io/posts/git-commit/
> > >
> > > Regards,
> > >
> > > *Raúl Kripalani*
> > > PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data
> and
> > > Messaging Engineer
> > > http://about.me/raulkripalani |
> http://www.linkedin.com/in/raulkripalani
> > > http://blog.raulkr.net | twitter: @raulvk
> >
>
--
--
Pavel Tupitsyn
GridGain Systems, Inc.
www.gridgain.com
Re: Let's please fix the mess in Git
Posted by Sergi Vladykin <se...@gmail.com>.
Raul,
First of all I think it is not an excuse that you did bad thing because
others did as well.
Lets try to be perfect ourselves before blaming others.
Do you know how I lately solve these issues with comments, squashing and
other stuff?
I do not do any merges of *my* changes to master at all. Almost never.
I just provide pull request on GitHub and ask a reviewer to merge it or
return with comments.
And when someone asks me to do the same I just do it using provided script
*scripts/apply-pull-request.sh*
There is no chance to do something wrong here.
I encourage you to do the same and all of your questions will disappear in
a second.
Sergi
2015-10-01 1:52 GMT+03:00 Konstantin Boudnik <co...@apache.org>:
> On Wed, Sep 30, 2015 at 09:32PM, Raul Kripalani wrote:
> > Igniters,
> >
> > 1. Git history is polluted by lots of commits like: "Merge
> remote-tracking
> > branch 'origin/ignite-1.4' into ignite-1.4". Is there a logical reason
> for
> > this? Why doesn't the team use git pull --rebase?
> >
> > 2. Let's please define a policy for Git commit messages. The current Git
> > history is an *utter mess*. This is totally unacceptable on master:
> > https://imgur.com/I95TPMd.
> >
> > a. Commit messages must carry a context. You should not oblige your
> > fellows to dig into the diff to understand what you've done.
> >
> > b. Even if you are referencing a JIRA ticket, please include some
> > context. Nobody remembers ticket numbers by heart and it's a waste of
> time
> > to open a browser tab for every commit.
> >
> > c. Pasting the full JIRA URL is wasteful and uses precious real
> estate.
> > Everybody knows that if you refer to IGNITE-nnnn, you're referring to an
> > ASF JIRA ticket.
> >
> > I agree with many of the tips on this post about Git commit message best
> > practices [1]. I suggest you read if you haven't yet.
> >
> > 3. Let's clarify the merging policy. Yakov complained because I merged a
> > branch without squashing. But I see people are doing this. He also
> > referenced a Wiki page that explained the procedure for Github pull
> > requests. Are we allowed to merge internal branches without squashing?
>
> We shouldn't be. We had this lengthy discussion about proper git practices
> where it has been established that squashing of intermediate commits is a
> blessing because
> a) no one is interested in "Oh, heck - I forgot the letter" commits
> b) rebase-then-merge allows to avoid meaningless "Merge commits", which
> might
> only be valuable for bring in some big feature branches, etc.
>
> Good points on the rest of it as well - let's have some discipline around
> this.
>
> Cos
> >
> > [1] http://chris.beams.io/posts/git-commit/
> >
> > Regards,
> >
> > *Raúl Kripalani*
> > PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
> > Messaging Engineer
> > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> > http://blog.raulkr.net | twitter: @raulvk
>