You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by James Taylor <ja...@apache.org> on 2014/02/01 04:08:06 UTC
Re: best development methodology for Apache git?
The folks over at jcloud use this as their methodology:
http://wiki.apache.org/jclouds/Committers%20Guide
Seems reasonable to me (with my Github bias :-)
Thoughts?
On Thu, Jan 30, 2014 at 6:50 PM, James Taylor <ja...@apache.org>wrote:
> Seems like Jake said "no" by closing it the INFRA ticket. I'll ask on the
> general list on ideas for a development methodology similar to github and
> mention Gerrit, but I may have already worn out my welcome by pestering him
> to import our github issues. :-(
>
>
> On Thu, Jan 30, 2014 at 6:42 PM, Nick Dimiduk <nd...@gmail.com> wrote:
>
>> Looking again at the comments on the INFRA ticket, I think there's enough
>> interest to justify its completion. I guess it's really up to Jukka and
>> Jake.
>>
>> On Thursday, January 30, 2014, James Taylor
>> <jamestaylor@apache.org<javascript:_e(%7B%7D,'cvml','
>> jamestaylor@apache.org');>>
>> wrote:
>>
>> > Gerrit sounds ideal, but is it an option?
>> >
>> >
>> > On Thu, Jan 30, 2014 at 5:55 PM, Nick Dimiduk <nd...@gmail.com>
>> wrote:
>> >
>> > > This is why I brought up Gerrit. It provides both a means for visually
>> > > reviewing patches (à la Github pull requests, Review Board) and
>> provides
>> > > the means to gate commits against the single source of truth
>> according to
>> > > the project guidelines, whatever they may be.
>> > >
>> > >
>> > > On Thu, Jan 30, 2014 at 5:03 PM, James Taylor <jamestaylor@apache.org
>> > > >wrote:
>> > >
>> > > > In what format is the patch given to you? Is it (or can it be) a
>> > > git-diff?
>> > > > And how do you visually apply the patch so that you can see it in
>> the
>> > > > context of the code (when you're evaluating it)?
>> > > >
>> > > > Our source-of-truth and record-of-what-happened is the Apache git
>> repo.
>> > > It
>> > > > would be nice if we could associate the committed SHAs with the JIRA
>> > > > (ideally in some automated way).
>> > > >
>> > > > Using review board sounds promising if it can be driven off of the
>> > > > git-diff.
>> > > >
>> > > > Seems like with a minimal amount of tooling, we could have a pretty
>> > good
>> > > > story. I think I'll ask on the general list, as other projects have
>> > gone
>> > > > through this transition already - maybe they have tooling that
>> could be
>> > > > leveraged?
>> > > >
>> > > > James
>> > > >
>> > > >
>> > > > On Thu, Jan 30, 2014 at 4:24 PM, lars hofhansl <la...@apache.org>
>> > wrote:
>> > > >
>> > > > > I'm a bit late to this party. In fact I asked James the exact same
>> > > thing
>> > > > > offline and missed that the discussion is already going on.
>> > > > >
>> > > > > It seems we should start with doing this the "HBase-way". I.e.
>> make
>> > > > > patches, attach then to the jira.
>> > > > > That way the jira/Apache-git is a full record of what happened
>> and we
>> > > do
>> > > > > not rely to two copies of the source (Apache and GitHub), of which
>> > one
>> > > > > might be behind.
>> > > > >
>> > > > > That leaves some power of git untapped (that even an oldfart like
>> me
>> > is
>> > > > > beginning to appreciate), and we should probably address that into
>> > the
>> > > > > future.
>> > > > >
>> > > > > So I'd vote for (1) patches on jira, (2) reviews on review board
>> when
>> > > > > needed, (3) no mandatory git hub involvement.
>> > > > >
>> > > > > -- Lars
>> > > > >
>> > > > >
>> > > > >
>> > > > > ________________________________
>> > > > > From: James Taylor <ja...@apache.org>
>> > > > > To: "dev@phoenix.incubator.apache.org" <
>> > > dev@phoenix.incubator.apache.org
>> > > > >
>> > > > > Sent: Tuesday, January 28, 2014 10:47 PM
>> > > > > Subject: best development methodology for Apache git?
>> > > > >
>> > > > >
>> > > > > I know you HBase guys use svn as your source of truth, but
>> Phoenix is
>> > > > using
>> > > > > git. With our old git repo which was hosted on github, we'd
>> typically
>> > > do
>> > > > > work locally and then send a pull request to the source-of-truth
>> > github
>> > > > > repo. That way others could comment on the pending commit before
>> it
>> > was
>> > > > > pulled in. Pulling it in could be done with a single click by
>> someone
>> > > > with
>> > > > > write privileges.
>> > > > >
>> > > > > Now, though, our source-of-truth is *not* on github, but on a git
>> > repo
>> > > > > hosted by Apache. It's only mirrored to github in a read-only
>> manner.
>> > > > Plus,
>> > > > > it may be lagging behind the source-of-truth repo.
>> > > > >
>> > > > > What's the best, recommended methodology and ui to use for getting
>> > > > > feedback
>> > > > > pre-commit?
>> > > > >
>> > > > > Thanks,
>> > > > > James
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
Re: best development methodology for Apache git?
Posted by Nick Dimiduk <nd...@gmail.com>.
Here's more details on the integration, just announced:
https://blogs.apache.org/infra/entry/improved_integration_between_apache_and
On Monday, February 10, 2014, James Taylor <ja...@apache.org> wrote:
> FYI, in case you're not following this on the general list, the INFRA guys
> have been working hard to improve the Github/Apache mail integration. If
> you link your Github user name with your Apache id by editing this file[1],
> when you open a pull requests on the Apache Github mirror, the dev list
> will get email. Comments on the pull request will go to the dev list too
> (only top level comments, not line comments). Also, if the title of pull
> request contains a JIRA ticket, the comment will appear in the JIRA as
> well.
>
> Thanks,
> James
>
> [1] https://svn.apache.org/repos/private/committers/docs/github_team.txt
>
>
> On Sat, Feb 8, 2014 at 11:41 PM, lars hofhansl <larsh@apache.org<javascript:;>>
> wrote:
>
> > Agreed. That was kinda my point earlier.
> > For a small patch/fix the least friction might be a patch to jira. Or
> > maybe a contributor prefers to send a pull request on GitHub.
> >
> > I think we should become familiar with all options (patch, GitHub, RB),
> so
> > that we can be friendly to contributors.
> >
> > -- Lars
> >
> > ------------------------------
> > *From:* James Taylor <jamestaylor@apache.org <javascript:;>>
> > *To:* Enis Söztutar <enis.soz@gmail.com <javascript:;>>
> > *Cc:* "dev@phoenix.incubator.apache.org <javascript:;>" <
> dev@phoenix.incubator.apache.org <javascript:;>>;
> > Andrew Purtell <apurtell@apache.org <javascript:;>>; James Taylor <
> jamestaylor@apache.org <javascript:;>>;
> > lars hofhansl <larsh@apache.org <javascript:;>>
> > *Sent:* Friday, February 7, 2014 4:37 PM
> > *Subject:* Re: best development methodology for Apache git?
> >
> > Good point. As long as the communication is happening efficiently, it
> > doesn't really matter what mechanism is used.
> >
> >
> > On Fri, Feb 7, 2014 at 4:19 PM, Enis Söztutar <en...@gmail.com>
> wrote:
> >
> > > I'll also suggest not requiring one method or the other. Meaning, "only
> > > github pull requests" or "only review board", etc. With community
> growing
> > > larger, we do not want to force people in one way. It should be always
> > > acceptable to attach patches to jira, and/or RB, or github.
> > >
> > > Enis
> > >
> > >
> > > On Thu, Feb 6, 2014 at 7:49 PM, James Taylor <jamestaylor@apache.org
> > >wrote:
> > >
> > >> To close the loop on this, unless there's strong opposition, let's
> > follow
> > >> the jclouds model documented here:
> > >> http://wiki.apache.org/jclouds/Committers%20Guide
> > >> We can also reference the JIRA on check-ins as Lars mentioned before.
> > >> INFRA
> > >> has already enabled our Github mirror to send a notification to our
> dev
> > >> list when a pull request is submitted.
> > >>
> > >> If this becomes burdensome or we find our mirror getting behind, we
> can
> > >> always revisit (or add more tooling).
> > >>
> > >> Thanks,
> > >> James
> > >>
> > >>
> > >>
> > >> On Fri, Jan 31, 2014 at 8:58 PM, Andrew Purtell <ap...@apache.org>
> > >> wrote:
> > >>
> > >> > It's your party James, in my opinion.
> > >> >
> > >> >
> > >> > On Friday, January 31, 2014, James Taylor <ja...@apache.org>
> > >> wrote:
> > >> >
> > >> >> The folks over at jcloud use this as their methodology:
> > >> >> http://wiki.apache.org/jclouds/Committers%20Guide
> > >> >>
> > >> >> Seems reasonable to me (with my Github bias :-)
> > >> >>
> > >> >> Thoughts?
> > >> >>
> > >> >>
> > >> >> On Thu, Jan 30, 2014 at 6:50 PM, James Taylor <
> > jamestaylor@apache.org
> > >> >> >wrote:
> > >> >>
> > >> >> > Seems like Jake said "no" by closing it the INFRA ticket. I'll
> ask
> > on
> > >> >> the
> > >> >> > general list on ideas for a development methodology similar to
> > github
> > >> >> and
> > >> >> > mention Gerrit, but I may have already worn out my welcome by
> > >> pestering
> > >> >> him
> > >> >> > to import our github issues. :-(
> > >> >> >
> > >> >> >
> > >> >> > On Thu, Jan 30, 2014 at 6:42 PM, Nick Dimiduk <
> ndimiduk@gmail.com>
> > >> >> wrote:
> > >> >> >
> > >> >> >> Looking again at the comments on the INFRA ticket, I think
> there's
> > >> >> enough
> > >> >> >> interest to justify its completion. I guess it's really up to
> > Jukka
> > >> and
> > >> >> >> Jake.
> > >> >> >>
> > >> >> >> On Thursday, January 30, 2014, James Taylor
> > >> >> >> <jamestaylor@apache.org<javascript:_e(%7B%7D,'cvml','
> > >> >> >> jamestaylor@apache.org');>>
> > >> >> >> wrote:
> > >> >> >>
> > >> >> >> > Gerrit sounds ideal, but is it an option?
> > >> >> >> >
> > >> >> >> >
> > >> >> >> > On
Re: best development methodology for Apache git?
Posted by James Taylor <ja...@apache.org>.
FYI, in case you're not following this on the general list, the INFRA guys
have been working hard to improve the Github/Apache mail integration. If
you link your Github user name with your Apache id by editing this file[1],
when you open a pull requests on the Apache Github mirror, the dev list
will get email. Comments on the pull request will go to the dev list too
(only top level comments, not line comments). Also, if the title of pull
request contains a JIRA ticket, the comment will appear in the JIRA as well.
Thanks,
James
[1] https://svn.apache.org/repos/private/committers/docs/github_team.txt
On Sat, Feb 8, 2014 at 11:41 PM, lars hofhansl <la...@apache.org> wrote:
> Agreed. That was kinda my point earlier.
> For a small patch/fix the least friction might be a patch to jira. Or
> maybe a contributor prefers to send a pull request on GitHub.
>
> I think we should become familiar with all options (patch, GitHub, RB), so
> that we can be friendly to contributors.
>
> -- Lars
>
> ------------------------------
> *From:* James Taylor <ja...@apache.org>
> *To:* Enis Söztutar <en...@gmail.com>
> *Cc:* "dev@phoenix.incubator.apache.org" <de...@phoenix.incubator.apache.org>;
> Andrew Purtell <ap...@apache.org>; James Taylor <ja...@apache.org>;
> lars hofhansl <la...@apache.org>
> *Sent:* Friday, February 7, 2014 4:37 PM
> *Subject:* Re: best development methodology for Apache git?
>
> Good point. As long as the communication is happening efficiently, it
> doesn't really matter what mechanism is used.
>
>
> On Fri, Feb 7, 2014 at 4:19 PM, Enis Söztutar <en...@gmail.com> wrote:
>
> > I'll also suggest not requiring one method or the other. Meaning, "only
> > github pull requests" or "only review board", etc. With community growing
> > larger, we do not want to force people in one way. It should be always
> > acceptable to attach patches to jira, and/or RB, or github.
> >
> > Enis
> >
> >
> > On Thu, Feb 6, 2014 at 7:49 PM, James Taylor <jamestaylor@apache.org
> >wrote:
> >
> >> To close the loop on this, unless there's strong opposition, let's
> follow
> >> the jclouds model documented here:
> >> http://wiki.apache.org/jclouds/Committers%20Guide
> >> We can also reference the JIRA on check-ins as Lars mentioned before.
> >> INFRA
> >> has already enabled our Github mirror to send a notification to our dev
> >> list when a pull request is submitted.
> >>
> >> If this becomes burdensome or we find our mirror getting behind, we can
> >> always revisit (or add more tooling).
> >>
> >> Thanks,
> >> James
> >>
> >>
> >>
> >> On Fri, Jan 31, 2014 at 8:58 PM, Andrew Purtell <ap...@apache.org>
> >> wrote:
> >>
> >> > It's your party James, in my opinion.
> >> >
> >> >
> >> > On Friday, January 31, 2014, James Taylor <ja...@apache.org>
> >> wrote:
> >> >
> >> >> The folks over at jcloud use this as their methodology:
> >> >> http://wiki.apache.org/jclouds/Committers%20Guide
> >> >>
> >> >> Seems reasonable to me (with my Github bias :-)
> >> >>
> >> >> Thoughts?
> >> >>
> >> >>
> >> >> On Thu, Jan 30, 2014 at 6:50 PM, James Taylor <
> jamestaylor@apache.org
> >> >> >wrote:
> >> >>
> >> >> > Seems like Jake said "no" by closing it the INFRA ticket. I'll ask
> on
> >> >> the
> >> >> > general list on ideas for a development methodology similar to
> github
> >> >> and
> >> >> > mention Gerrit, but I may have already worn out my welcome by
> >> pestering
> >> >> him
> >> >> > to import our github issues. :-(
> >> >> >
> >> >> >
> >> >> > On Thu, Jan 30, 2014 at 6:42 PM, Nick Dimiduk <nd...@gmail.com>
> >> >> wrote:
> >> >> >
> >> >> >> Looking again at the comments on the INFRA ticket, I think there's
> >> >> enough
> >> >> >> interest to justify its completion. I guess it's really up to
> Jukka
> >> and
> >> >> >> Jake.
> >> >> >>
> >> >> >> On Thursday, January 30, 2014, James Taylor
> >> >> >> <jamestaylor@apache.org<javascript:_e(%7B%7D,'cvml','
> >> >> >> jamestaylor@apache.org');>>
> >> >> >> wrote:
> >> >> >>
> >> >> >> > Gerrit sounds ideal, but is it an option?
> >> >> >> >
> >> >> >> >
> >> >> >> > On Thu, Jan 30, 2014 at 5:55 PM, Nick Dimiduk <
> ndimiduk@gmail.com
> >> >
> >> >> >> wrote:
> >> >> >> >
> >> >> >> > > This is why I brought up Gerrit. It provides both a means for
> >> >> visually
> >> >> >> > > reviewing patches (à la Github pull requests, Review Board)
> and
> >> >> >> provides
> >> >> >> > > the means to gate commits against the single source of truth
> >> >> >> according to
> >> >> >> > > the project guidelines, whatever they may be.
> >> >> >> > >
> >> >> >> > >
> >> >> >> > > On Thu, Jan 30, 2014 at 5:03 PM, James Taylor <
> >> >> jamestaylor@apache.org
> >> >> >> > > >wrote:
> >> >> >> > >
> >> >> >> > > > In what format is the patch given to you? Is it (or can it
> >> be) a
> >> >> >> > > git-diff?
> >> >> >> > > > And how do you visually apply the patch so that you can see
> >> it in
> >> >> >> the
> >> >> >> > > > context of the code (when you're evaluating it)?
> >> >> >> > > >
> >> >> >> > > > Our source-of-truth and record-of-what-happened is the
> Apache
> >> git
> >> >> >> repo.
> >> >> >> > > It
> >> >> >> > > > would be nice if we could associate the committed SHAs with
> >> the
> >> >> JIRA
> >> >> >> > > > (ideally in some automated way).
> >> >> >> > > >
> >> >> >> > > > Using review board sounds promising if it can be driven off
> of
> >> >> the
> >> >> >> > > > git-diff.
> >> >> >> > > >
> >> >> >> > > > Seems like with a minimal amount of tooling, we could have a
> >> >> pretty
> >> >> >> > good
> >> >> >> > > > story. I think I'll ask on the general list, as other
> projects
> >> >> have
> >> >> >> > gone
> >> >> >> > > > through this transition already - maybe they have tooling
> that
> >> >> >> could be
> >> >> >> > > > leveraged?
> >> >> >> > > >
> >> >> >> > > > James
> >> >> >> > > >
> >> >> >> > > >
> >> >> >> > > > On Thu, Jan 30, 2014 at 4:24 PM, lars hofhansl <
> >> larsh@apache.org
> >> >> >
> >> >> >> > wrote:
> >> >> >> > > >
> >> >> >> > > > > I'm a bit late to this party. In fact I asked James the
> >> exact
> >> >> same
> >> >> >> > > thing
> >> >> >> > > > > offline and missed that the discussion is already going
> on.
> >> >> >> > > > >
> >> >> >> > > > > It seems we should start with doing this the "HBase-way".
> >> I.e.
> >> >> >> make
> >> >> >> > > > > patches, attach then to the jira.
> >> >> >> > > > > That way the jira/Apache-git is a full record of what
> >> happened
> >> >> >> and we
> >> >> >> > > do
> >> >> >> > > > > not rely to two copies of the source (Apache and GitHub),
> of
> >> >> which
> >> >> >> > one
> >> >> >> > > > > might be behind.
> >> >> >> > > > >
> >> >> >> > > > > That leaves some power of git untapped (that even an
> oldfart
> >> >> like
> >> >> >> me
> >> >> >> > is
> >> >> >> > > > > beginning to appreciate), and we should probably address
> >> that
> >> >> into
> >> >> >> > the
> >> >> >> > > > > future.
> >> >> >> > > > >
> >> >> >> > > > > So I'd vote for (1) patches on jira, (2) reviews on review
> >> >> board
> >> >> >> when
> >> >> >> > > > > needed, (3) no mandatory git hub involvement.
> >> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Best regards,
> >> >
> >> > - Andy
> >> >
> >> > Problems worthy of attack prove their worth by hitting back. - Piet
> Hein
> >> > (via Tom White)
> >> >
> >> >
> >>
> >
> >
>
>
>
Re: best development methodology for Apache git?
Posted by lars hofhansl <la...@apache.org>.
Agreed. That was kinda my point earlier.
For a small patch/fix the least friction might be a patch to jira. Or maybe a contributor prefers to send a pull request on GitHub.
I think we should become familiar with all options (patch, GitHub, RB), so that we can be friendly to contributors.
-- Lars
________________________________
From: James Taylor <ja...@apache.org>
To: Enis Söztutar <en...@gmail.com>
Cc: "dev@phoenix.incubator.apache.org" <de...@phoenix.incubator.apache.org>; Andrew Purtell <ap...@apache.org>; James Taylor <ja...@apache.org>; lars hofhansl <la...@apache.org>
Sent: Friday, February 7, 2014 4:37 PM
Subject: Re: best development methodology for Apache git?
Good point. As long as the communication is happening efficiently, it
doesn't really matter what mechanism is used.
On Fri, Feb 7, 2014 at 4:19 PM, Enis Söztutar <en...@gmail.com> wrote:
> I'll also suggest not requiring one method or the other. Meaning, "only
> github pull requests" or "only review board", etc. With community growing
> larger, we do not want to force people in one way. It should be always
> acceptable to attach patches to jira, and/or RB, or github.
>
> Enis
>
>
> On Thu, Feb 6, 2014 at 7:49 PM, James Taylor <ja...@apache.org>wrote:
>
>> To close the loop on this, unless there's strong opposition, let's follow
>> the jclouds model documented here:
>> http://wiki.apache.org/jclouds/Committers%20Guide
>> We can also reference the JIRA on check-ins as Lars mentioned before.
>> INFRA
>> has already enabled our Github mirror to send a notification to our dev
>> list when a pull request is submitted.
>>
>> If this becomes burdensome or we find our mirror getting behind, we can
>> always revisit (or add more tooling).
>>
>> Thanks,
>> James
>>
>>
>>
>> On Fri, Jan 31, 2014 at 8:58 PM, Andrew Purtell <ap...@apache.org>
>> wrote:
>>
>> > It's your party James, in my opinion.
>> >
>> >
>> > On Friday, January 31, 2014, James Taylor <ja...@apache.org>
>> wrote:
>> >
>> >> The folks over at jcloud use this as their methodology:
>> >> http://wiki.apache.org/jclouds/Committers%20Guide
>> >>
>> >> Seems reasonable to me (with my Github bias :-)
>> >>
>> >> Thoughts?
>> >>
>> >>
>> >> On Thu, Jan 30, 2014 at 6:50 PM, James Taylor <jamestaylor@apache.org
>> >> >wrote:
>> >>
>> >> > Seems like Jake said "no" by closing it the INFRA ticket. I'll ask on
>> >> the
>> >> > general list on ideas for a development methodology similar to github
>> >> and
>> >> > mention Gerrit, but I may have already worn out my welcome by
>> pestering
>> >> him
>> >> > to import our github issues. :-(
>> >> >
>> >> >
>> >> > On Thu, Jan 30, 2014 at 6:42 PM, Nick Dimiduk <nd...@gmail.com>
>> >> wrote:
>> >> >
>> >> >> Looking again at the comments on the INFRA ticket, I think there's
>> >> enough
>> >> >> interest to justify its completion. I guess it's really up to Jukka
>> and
>> >> >> Jake.
>> >> >>
>> >> >> On Thursday, January 30, 2014, James Taylor
>> >> >> <jamestaylor@apache.org<javascript:_e(%7B%7D,'cvml','
>> >> >> jamestaylor@apache.org');>>
>> >> >> wrote:
>> >> >>
>> >> >> > Gerrit sounds ideal, but is it an option?
>> >> >> >
>> >> >> >
>> >> >> > On Thu, Jan 30, 2014 at 5:55 PM, Nick Dimiduk <ndimiduk@gmail.com
>> >
>> >> >> wrote:
>> >> >> >
>> >> >> > > This is why I brought up Gerrit. It provides both a means for
>> >> visually
>> >> >> > > reviewing patches (à la Github pull requests, Review Board) and
>> >> >> provides
>> >> >> > > the means to gate commits against the single source of truth
>> >> >> according to
>> >> >> > > the project guidelines, whatever they may be.
>> >> >> > >
>> >> >> > >
>> >> >> > > On Thu, Jan 30, 2014 at 5:03 PM, James Taylor <
>> >> jamestaylor@apache.org
>> >> >> > > >wrote:
>> >> >> > >
>> >> >> > > > In what format is the patch given to you? Is it (or can it
>> be) a
>> >> >> > > git-diff?
>> >> >> > > > And how do you visually apply the patch so that you can see
>> it in
>> >> >> the
>> >> >> > > > context of the code (when you're evaluating it)?
>> >> >> > > >
>> >> >> > > > Our source-of-truth and record-of-what-happened is the Apache
>> git
>> >> >> repo.
>> >> >> > > It
>> >> >> > > > would be nice if we could associate the committed SHAs with
>> the
>> >> JIRA
>> >> >> > > > (ideally in some automated way).
>> >> >> > > >
>> >> >> > > > Using review board sounds promising if it can be driven off of
>> >> the
>> >> >> > > > git-diff.
>> >> >> > > >
>> >> >> > > > Seems like with a minimal amount of tooling, we could have a
>> >> pretty
>> >> >> > good
>> >> >> > > > story. I think I'll ask on the general list, as other projects
>> >> have
>> >> >> > gone
>> >> >> > > > through this transition already - maybe they have tooling that
>> >> >> could be
>> >> >> > > > leveraged?
>> >> >> > > >
>> >> >> > > > James
>> >> >> > > >
>> >> >> > > >
>> >> >> > > > On Thu, Jan 30, 2014 at 4:24 PM, lars hofhansl <
>> larsh@apache.org
>> >> >
>> >> >> > wrote:
>> >> >> > > >
>> >> >> > > > > I'm a bit late to this party. In fact I asked James the
>> exact
>> >> same
>> >> >> > > thing
>> >> >> > > > > offline and missed that the discussion is already going on.
>> >> >> > > > >
>> >> >> > > > > It seems we should start with doing this the "HBase-way".
>> I.e.
>> >> >> make
>> >> >> > > > > patches, attach then to the jira.
>> >> >> > > > > That way the jira/Apache-git is a full record of what
>> happened
>> >> >> and we
>> >> >> > > do
>> >> >> > > > > not rely to two copies of the source (Apache and GitHub), of
>> >> which
>> >> >> > one
>> >> >> > > > > might be behind.
>> >> >> > > > >
>> >> >> > > > > That leaves some power of git untapped (that even an oldfart
>> >> like
>> >> >> me
>> >> >> > is
>> >> >> > > > > beginning to appreciate), and we should probably address
>> that
>> >> into
>> >> >> > the
>> >> >> > > > > future.
>> >> >> > > > >
>> >> >> > > > > So I'd vote for (1) patches on jira, (2) reviews on review
>> >> board
>> >> >> when
>> >> >> > > > > needed, (3) no mandatory git hub involvement.
>> >> >>
>> >
>> >
>> >
>> > --
>> > Best regards,
>> >
>> > - Andy
>> >
>> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
>> > (via Tom White)
>> >
>> >
>>
>
>
Re: best development methodology for Apache git?
Posted by James Taylor <ja...@apache.org>.
Good point. As long as the communication is happening efficiently, it
doesn't really matter what mechanism is used.
On Fri, Feb 7, 2014 at 4:19 PM, Enis Söztutar <en...@gmail.com> wrote:
> I'll also suggest not requiring one method or the other. Meaning, "only
> github pull requests" or "only review board", etc. With community growing
> larger, we do not want to force people in one way. It should be always
> acceptable to attach patches to jira, and/or RB, or github.
>
> Enis
>
>
> On Thu, Feb 6, 2014 at 7:49 PM, James Taylor <ja...@apache.org>wrote:
>
>> To close the loop on this, unless there's strong opposition, let's follow
>> the jclouds model documented here:
>> http://wiki.apache.org/jclouds/Committers%20Guide
>> We can also reference the JIRA on check-ins as Lars mentioned before.
>> INFRA
>> has already enabled our Github mirror to send a notification to our dev
>> list when a pull request is submitted.
>>
>> If this becomes burdensome or we find our mirror getting behind, we can
>> always revisit (or add more tooling).
>>
>> Thanks,
>> James
>>
>>
>>
>> On Fri, Jan 31, 2014 at 8:58 PM, Andrew Purtell <ap...@apache.org>
>> wrote:
>>
>> > It's your party James, in my opinion.
>> >
>> >
>> > On Friday, January 31, 2014, James Taylor <ja...@apache.org>
>> wrote:
>> >
>> >> The folks over at jcloud use this as their methodology:
>> >> http://wiki.apache.org/jclouds/Committers%20Guide
>> >>
>> >> Seems reasonable to me (with my Github bias :-)
>> >>
>> >> Thoughts?
>> >>
>> >>
>> >> On Thu, Jan 30, 2014 at 6:50 PM, James Taylor <jamestaylor@apache.org
>> >> >wrote:
>> >>
>> >> > Seems like Jake said "no" by closing it the INFRA ticket. I'll ask on
>> >> the
>> >> > general list on ideas for a development methodology similar to github
>> >> and
>> >> > mention Gerrit, but I may have already worn out my welcome by
>> pestering
>> >> him
>> >> > to import our github issues. :-(
>> >> >
>> >> >
>> >> > On Thu, Jan 30, 2014 at 6:42 PM, Nick Dimiduk <nd...@gmail.com>
>> >> wrote:
>> >> >
>> >> >> Looking again at the comments on the INFRA ticket, I think there's
>> >> enough
>> >> >> interest to justify its completion. I guess it's really up to Jukka
>> and
>> >> >> Jake.
>> >> >>
>> >> >> On Thursday, January 30, 2014, James Taylor
>> >> >> <jamestaylor@apache.org<javascript:_e(%7B%7D,'cvml','
>> >> >> jamestaylor@apache.org');>>
>> >> >> wrote:
>> >> >>
>> >> >> > Gerrit sounds ideal, but is it an option?
>> >> >> >
>> >> >> >
>> >> >> > On Thu, Jan 30, 2014 at 5:55 PM, Nick Dimiduk <ndimiduk@gmail.com
>> >
>> >> >> wrote:
>> >> >> >
>> >> >> > > This is why I brought up Gerrit. It provides both a means for
>> >> visually
>> >> >> > > reviewing patches (à la Github pull requests, Review Board) and
>> >> >> provides
>> >> >> > > the means to gate commits against the single source of truth
>> >> >> according to
>> >> >> > > the project guidelines, whatever they may be.
>> >> >> > >
>> >> >> > >
>> >> >> > > On Thu, Jan 30, 2014 at 5:03 PM, James Taylor <
>> >> jamestaylor@apache.org
>> >> >> > > >wrote:
>> >> >> > >
>> >> >> > > > In what format is the patch given to you? Is it (or can it
>> be) a
>> >> >> > > git-diff?
>> >> >> > > > And how do you visually apply the patch so that you can see
>> it in
>> >> >> the
>> >> >> > > > context of the code (when you're evaluating it)?
>> >> >> > > >
>> >> >> > > > Our source-of-truth and record-of-what-happened is the Apache
>> git
>> >> >> repo.
>> >> >> > > It
>> >> >> > > > would be nice if we could associate the committed SHAs with
>> the
>> >> JIRA
>> >> >> > > > (ideally in some automated way).
>> >> >> > > >
>> >> >> > > > Using review board sounds promising if it can be driven off of
>> >> the
>> >> >> > > > git-diff.
>> >> >> > > >
>> >> >> > > > Seems like with a minimal amount of tooling, we could have a
>> >> pretty
>> >> >> > good
>> >> >> > > > story. I think I'll ask on the general list, as other projects
>> >> have
>> >> >> > gone
>> >> >> > > > through this transition already - maybe they have tooling that
>> >> >> could be
>> >> >> > > > leveraged?
>> >> >> > > >
>> >> >> > > > James
>> >> >> > > >
>> >> >> > > >
>> >> >> > > > On Thu, Jan 30, 2014 at 4:24 PM, lars hofhansl <
>> larsh@apache.org
>> >> >
>> >> >> > wrote:
>> >> >> > > >
>> >> >> > > > > I'm a bit late to this party. In fact I asked James the
>> exact
>> >> same
>> >> >> > > thing
>> >> >> > > > > offline and missed that the discussion is already going on.
>> >> >> > > > >
>> >> >> > > > > It seems we should start with doing this the "HBase-way".
>> I.e.
>> >> >> make
>> >> >> > > > > patches, attach then to the jira.
>> >> >> > > > > That way the jira/Apache-git is a full record of what
>> happened
>> >> >> and we
>> >> >> > > do
>> >> >> > > > > not rely to two copies of the source (Apache and GitHub), of
>> >> which
>> >> >> > one
>> >> >> > > > > might be behind.
>> >> >> > > > >
>> >> >> > > > > That leaves some power of git untapped (that even an oldfart
>> >> like
>> >> >> me
>> >> >> > is
>> >> >> > > > > beginning to appreciate), and we should probably address
>> that
>> >> into
>> >> >> > the
>> >> >> > > > > future.
>> >> >> > > > >
>> >> >> > > > > So I'd vote for (1) patches on jira, (2) reviews on review
>> >> board
>> >> >> when
>> >> >> > > > > needed, (3) no mandatory git hub involvement.
>> >> >>
>> >
>> >
>> >
>> > --
>> > Best regards,
>> >
>> > - Andy
>> >
>> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
>> > (via Tom White)
>> >
>> >
>>
>
>
Re: best development methodology for Apache git?
Posted by Enis Söztutar <en...@gmail.com>.
I'll also suggest not requiring one method or the other. Meaning, "only
github pull requests" or "only review board", etc. With community growing
larger, we do not want to force people in one way. It should be always
acceptable to attach patches to jira, and/or RB, or github.
Enis
On Thu, Feb 6, 2014 at 7:49 PM, James Taylor <ja...@apache.org> wrote:
> To close the loop on this, unless there's strong opposition, let's follow
> the jclouds model documented here:
> http://wiki.apache.org/jclouds/Committers%20Guide
> We can also reference the JIRA on check-ins as Lars mentioned before. INFRA
> has already enabled our Github mirror to send a notification to our dev
> list when a pull request is submitted.
>
> If this becomes burdensome or we find our mirror getting behind, we can
> always revisit (or add more tooling).
>
> Thanks,
> James
>
>
>
> On Fri, Jan 31, 2014 at 8:58 PM, Andrew Purtell <ap...@apache.org>
> wrote:
>
> > It's your party James, in my opinion.
> >
> >
> > On Friday, January 31, 2014, James Taylor <ja...@apache.org>
> wrote:
> >
> >> The folks over at jcloud use this as their methodology:
> >> http://wiki.apache.org/jclouds/Committers%20Guide
> >>
> >> Seems reasonable to me (with my Github bias :-)
> >>
> >> Thoughts?
> >>
> >>
> >> On Thu, Jan 30, 2014 at 6:50 PM, James Taylor <jamestaylor@apache.org
> >> >wrote:
> >>
> >> > Seems like Jake said "no" by closing it the INFRA ticket. I'll ask on
> >> the
> >> > general list on ideas for a development methodology similar to github
> >> and
> >> > mention Gerrit, but I may have already worn out my welcome by
> pestering
> >> him
> >> > to import our github issues. :-(
> >> >
> >> >
> >> > On Thu, Jan 30, 2014 at 6:42 PM, Nick Dimiduk <nd...@gmail.com>
> >> wrote:
> >> >
> >> >> Looking again at the comments on the INFRA ticket, I think there's
> >> enough
> >> >> interest to justify its completion. I guess it's really up to Jukka
> and
> >> >> Jake.
> >> >>
> >> >> On Thursday, January 30, 2014, James Taylor
> >> >> <jamestaylor@apache.org<javascript:_e(%7B%7D,'cvml','
> >> >> jamestaylor@apache.org');>>
> >> >> wrote:
> >> >>
> >> >> > Gerrit sounds ideal, but is it an option?
> >> >> >
> >> >> >
> >> >> > On Thu, Jan 30, 2014 at 5:55 PM, Nick Dimiduk <nd...@gmail.com>
> >> >> wrote:
> >> >> >
> >> >> > > This is why I brought up Gerrit. It provides both a means for
> >> visually
> >> >> > > reviewing patches (à la Github pull requests, Review Board) and
> >> >> provides
> >> >> > > the means to gate commits against the single source of truth
> >> >> according to
> >> >> > > the project guidelines, whatever they may be.
> >> >> > >
> >> >> > >
> >> >> > > On Thu, Jan 30, 2014 at 5:03 PM, James Taylor <
> >> jamestaylor@apache.org
> >> >> > > >wrote:
> >> >> > >
> >> >> > > > In what format is the patch given to you? Is it (or can it be)
> a
> >> >> > > git-diff?
> >> >> > > > And how do you visually apply the patch so that you can see it
> in
> >> >> the
> >> >> > > > context of the code (when you're evaluating it)?
> >> >> > > >
> >> >> > > > Our source-of-truth and record-of-what-happened is the Apache
> git
> >> >> repo.
> >> >> > > It
> >> >> > > > would be nice if we could associate the committed SHAs with the
> >> JIRA
> >> >> > > > (ideally in some automated way).
> >> >> > > >
> >> >> > > > Using review board sounds promising if it can be driven off of
> >> the
> >> >> > > > git-diff.
> >> >> > > >
> >> >> > > > Seems like with a minimal amount of tooling, we could have a
> >> pretty
> >> >> > good
> >> >> > > > story. I think I'll ask on the general list, as other projects
> >> have
> >> >> > gone
> >> >> > > > through this transition already - maybe they have tooling that
> >> >> could be
> >> >> > > > leveraged?
> >> >> > > >
> >> >> > > > James
> >> >> > > >
> >> >> > > >
> >> >> > > > On Thu, Jan 30, 2014 at 4:24 PM, lars hofhansl <
> larsh@apache.org
> >> >
> >> >> > wrote:
> >> >> > > >
> >> >> > > > > I'm a bit late to this party. In fact I asked James the exact
> >> same
> >> >> > > thing
> >> >> > > > > offline and missed that the discussion is already going on.
> >> >> > > > >
> >> >> > > > > It seems we should start with doing this the "HBase-way".
> I.e.
> >> >> make
> >> >> > > > > patches, attach then to the jira.
> >> >> > > > > That way the jira/Apache-git is a full record of what
> happened
> >> >> and we
> >> >> > > do
> >> >> > > > > not rely to two copies of the source (Apache and GitHub), of
> >> which
> >> >> > one
> >> >> > > > > might be behind.
> >> >> > > > >
> >> >> > > > > That leaves some power of git untapped (that even an oldfart
> >> like
> >> >> me
> >> >> > is
> >> >> > > > > beginning to appreciate), and we should probably address that
> >> into
> >> >> > the
> >> >> > > > > future.
> >> >> > > > >
> >> >> > > > > So I'd vote for (1) patches on jira, (2) reviews on review
> >> board
> >> >> when
> >> >> > > > > needed, (3) no mandatory git hub involvement.
> >> >>
> >
> >
> >
> > --
> > Best regards,
> >
> > - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
> >
>
Re: best development methodology for Apache git?
Posted by James Taylor <ja...@apache.org>.
To close the loop on this, unless there's strong opposition, let's follow
the jclouds model documented here:
http://wiki.apache.org/jclouds/Committers%20Guide
We can also reference the JIRA on check-ins as Lars mentioned before. INFRA
has already enabled our Github mirror to send a notification to our dev
list when a pull request is submitted.
If this becomes burdensome or we find our mirror getting behind, we can
always revisit (or add more tooling).
Thanks,
James
On Fri, Jan 31, 2014 at 8:58 PM, Andrew Purtell <ap...@apache.org> wrote:
> It's your party James, in my opinion.
>
>
> On Friday, January 31, 2014, James Taylor <ja...@apache.org> wrote:
>
>> The folks over at jcloud use this as their methodology:
>> http://wiki.apache.org/jclouds/Committers%20Guide
>>
>> Seems reasonable to me (with my Github bias :-)
>>
>> Thoughts?
>>
>>
>> On Thu, Jan 30, 2014 at 6:50 PM, James Taylor <jamestaylor@apache.org
>> >wrote:
>>
>> > Seems like Jake said "no" by closing it the INFRA ticket. I'll ask on
>> the
>> > general list on ideas for a development methodology similar to github
>> and
>> > mention Gerrit, but I may have already worn out my welcome by pestering
>> him
>> > to import our github issues. :-(
>> >
>> >
>> > On Thu, Jan 30, 2014 at 6:42 PM, Nick Dimiduk <nd...@gmail.com>
>> wrote:
>> >
>> >> Looking again at the comments on the INFRA ticket, I think there's
>> enough
>> >> interest to justify its completion. I guess it's really up to Jukka and
>> >> Jake.
>> >>
>> >> On Thursday, January 30, 2014, James Taylor
>> >> <jamestaylor@apache.org<javascript:_e(%7B%7D,'cvml','
>> >> jamestaylor@apache.org');>>
>> >> wrote:
>> >>
>> >> > Gerrit sounds ideal, but is it an option?
>> >> >
>> >> >
>> >> > On Thu, Jan 30, 2014 at 5:55 PM, Nick Dimiduk <nd...@gmail.com>
>> >> wrote:
>> >> >
>> >> > > This is why I brought up Gerrit. It provides both a means for
>> visually
>> >> > > reviewing patches (à la Github pull requests, Review Board) and
>> >> provides
>> >> > > the means to gate commits against the single source of truth
>> >> according to
>> >> > > the project guidelines, whatever they may be.
>> >> > >
>> >> > >
>> >> > > On Thu, Jan 30, 2014 at 5:03 PM, James Taylor <
>> jamestaylor@apache.org
>> >> > > >wrote:
>> >> > >
>> >> > > > In what format is the patch given to you? Is it (or can it be) a
>> >> > > git-diff?
>> >> > > > And how do you visually apply the patch so that you can see it in
>> >> the
>> >> > > > context of the code (when you're evaluating it)?
>> >> > > >
>> >> > > > Our source-of-truth and record-of-what-happened is the Apache git
>> >> repo.
>> >> > > It
>> >> > > > would be nice if we could associate the committed SHAs with the
>> JIRA
>> >> > > > (ideally in some automated way).
>> >> > > >
>> >> > > > Using review board sounds promising if it can be driven off of
>> the
>> >> > > > git-diff.
>> >> > > >
>> >> > > > Seems like with a minimal amount of tooling, we could have a
>> pretty
>> >> > good
>> >> > > > story. I think I'll ask on the general list, as other projects
>> have
>> >> > gone
>> >> > > > through this transition already - maybe they have tooling that
>> >> could be
>> >> > > > leveraged?
>> >> > > >
>> >> > > > James
>> >> > > >
>> >> > > >
>> >> > > > On Thu, Jan 30, 2014 at 4:24 PM, lars hofhansl <larsh@apache.org
>> >
>> >> > wrote:
>> >> > > >
>> >> > > > > I'm a bit late to this party. In fact I asked James the exact
>> same
>> >> > > thing
>> >> > > > > offline and missed that the discussion is already going on.
>> >> > > > >
>> >> > > > > It seems we should start with doing this the "HBase-way". I.e.
>> >> make
>> >> > > > > patches, attach then to the jira.
>> >> > > > > That way the jira/Apache-git is a full record of what happened
>> >> and we
>> >> > > do
>> >> > > > > not rely to two copies of the source (Apache and GitHub), of
>> which
>> >> > one
>> >> > > > > might be behind.
>> >> > > > >
>> >> > > > > That leaves some power of git untapped (that even an oldfart
>> like
>> >> me
>> >> > is
>> >> > > > > beginning to appreciate), and we should probably address that
>> into
>> >> > the
>> >> > > > > future.
>> >> > > > >
>> >> > > > > So I'd vote for (1) patches on jira, (2) reviews on review
>> board
>> >> when
>> >> > > > > needed, (3) no mandatory git hub involvement.
>> >>
>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
>
Re: best development methodology for Apache git?
Posted by Andrew Purtell <ap...@apache.org>.
It's your party James, in my opinion.
On Friday, January 31, 2014, James Taylor <ja...@apache.org> wrote:
> The folks over at jcloud use this as their methodology:
> http://wiki.apache.org/jclouds/Committers%20Guide
>
> Seems reasonable to me (with my Github bias :-)
>
> Thoughts?
>
>
> On Thu, Jan 30, 2014 at 6:50 PM, James Taylor <jamestaylor@apache.org<javascript:;>
> >wrote:
>
> > Seems like Jake said "no" by closing it the INFRA ticket. I'll ask on the
> > general list on ideas for a development methodology similar to github and
> > mention Gerrit, but I may have already worn out my welcome by pestering
> him
> > to import our github issues. :-(
> >
> >
> > On Thu, Jan 30, 2014 at 6:42 PM, Nick Dimiduk <nd...@gmail.com>
> wrote:
> >
> >> Looking again at the comments on the INFRA ticket, I think there's
> enough
> >> interest to justify its completion. I guess it's really up to Jukka and
> >> Jake.
> >>
> >> On Thursday, January 30, 2014, James Taylor
> >> <jamestaylor@apache.org<javascript:_e(%7B%7D,'cvml','
> >> jamestaylor@apache.org');>>
> >> wrote:
> >>
> >> > Gerrit sounds ideal, but is it an option?
> >> >
> >> >
> >> > On Thu, Jan 30, 2014 at 5:55 PM, Nick Dimiduk <nd...@gmail.com>
> >> wrote:
> >> >
> >> > > This is why I brought up Gerrit. It provides both a means for
> visually
> >> > > reviewing patches (à la Github pull requests, Review Board) and
> >> provides
> >> > > the means to gate commits against the single source of truth
> >> according to
> >> > > the project guidelines, whatever they may be.
> >> > >
> >> > >
> >> > > On Thu, Jan 30, 2014 at 5:03 PM, James Taylor <
> jamestaylor@apache.org
> >> > > >wrote:
> >> > >
> >> > > > In what format is the patch given to you? Is it (or can it be) a
> >> > > git-diff?
> >> > > > And how do you visually apply the patch so that you can see it in
> >> the
> >> > > > context of the code (when you're evaluating it)?
> >> > > >
> >> > > > Our source-of-truth and record-of-what-happened is the Apache git
> >> repo.
> >> > > It
> >> > > > would be nice if we could associate the committed SHAs with the
> JIRA
> >> > > > (ideally in some automated way).
> >> > > >
> >> > > > Using review board sounds promising if it can be driven off of the
> >> > > > git-diff.
> >> > > >
> >> > > > Seems like with a minimal amount of tooling, we could have a
> pretty
> >> > good
> >> > > > story. I think I'll ask on the general list, as other projects
> have
> >> > gone
> >> > > > through this transition already - maybe they have tooling that
> >> could be
> >> > > > leveraged?
> >> > > >
> >> > > > James
> >> > > >
> >> > > >
> >> > > > On Thu, Jan 30, 2014 at 4:24 PM, lars hofhansl <la...@apache.org>
> >> > wrote:
> >> > > >
> >> > > > > I'm a bit late to this party. In fact I asked James the exact
> same
> >> > > thing
> >> > > > > offline and missed that the discussion is already going on.
> >> > > > >
> >> > > > > It seems we should start with doing this the "HBase-way". I.e.
> >> make
> >> > > > > patches, attach then to the jira.
> >> > > > > That way the jira/Apache-git is a full record of what happened
> >> and we
> >> > > do
> >> > > > > not rely to two copies of the source (Apache and GitHub), of
> which
> >> > one
> >> > > > > might be behind.
> >> > > > >
> >> > > > > That leaves some power of git untapped (that even an oldfart
> like
> >> me
> >> > is
> >> > > > > beginning to appreciate), and we should probably address that
> into
> >> > the
> >> > > > > future.
> >> > > > >
> >> > > > > So I'd vote for (1) patches on jira, (2) reviews on review board
> >> when
> >> > > > > needed, (3) no mandatory git hub involvement.
> >>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)