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/01/29 07:47:36 UTC
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 "Vasudevan, Ramkrishna S" <ra...@intel.com>.
I have not worked on the git repo in apache still. So we will give patches like in HBase but prepared using git? Or it is push/pull requests only? When I worked with the older Phoenix git repo we used to discuss on the UI provided by github.
Regards
Ram
-----Original Message-----
From: Devaraj Das [mailto:ddas@hortonworks.com]
Sent: Wednesday, January 29, 2014 12:24 PM
To: dev@phoenix.incubator.apache.org
Subject: Re: best development methodology for Apache git?
Hey James, couldn't we use the jira comments as a way to discuss/feedback, even though we use git repo?
On Tue, Jan 28, 2014 at 10:47 PM, James Taylor <ja...@apache.org> wrote:
> 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
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
Re: best development methodology for Apache git?
Posted by James Taylor <ja...@apache.org>.
Thanks, Jesse. Agree that (2) sounds like the best option. I'll ask on the
general list too.
What's the HadoopQA bot?
Thanks,
James
On Wednesday, January 29, 2014, Jesse Yates <je...@gmail.com> wrote:
> Git is just a source control system - it was github that lead to the
> prevalence of the pull requests and merges.
>
> Whatever we do for reviews, we basically need to use git like svn and fully
> sync the repo each time, apply the patch, and then commit. Git hosting just
> means ppl work in the same source control as the project and its easier to
> do things like feature branches.
>
> For reviews/discussion, Id recommend we do one of two things:
> 1. Do just what HBase does and post patches on Jiras, discuss there, and
> take any extra discussion to review board. This makes it really easy to
> follow for any downstream projects. However, review board only works on
> trunk - patches on older versions tend to be a bit harder to review.
>
> 2. Use jiras for discussion and then do reviews on pull requests against
> the apache github mirror. It can be a little out of date, but tends to be
> pretty close. The advantage being that can have reviews more easily against
> any branch. Once the review is good, the comitter would download the patch,
> attach it to the jira (so downstream projects can keep track of the jiras
> and their patches) and the commit it. I've heard of projects doing this,
> but can't recall the exact names right now.
>
> I'm leaning towards (2), but think either would work fine. Its just been a
> pain in the past for HBase when reviewing large 0.94 patches to have to
> manually review the patch, rather than use a really review tool; using pull
> requests would solve this, but adds a little complication to the process
> (though people still do pull requests against HBase sometimes, so maybe not
> so hard to figure out?)
>
> Just my $0.03
>
> --j
>
> PS we should also consider getting something like the HadoopQA bot going
> for phoenix too
> On Jan 28, 2014 11:10 PM, "Devaraj Das" <ddas@hortonworks.com<javascript:;>>
> wrote:
>
> > And there is reviewboard which is pretty widely used in HBase for the
> > code review (and that works off git repo too)..
> >
> > On Tue, Jan 28, 2014 at 10:54 PM, Devaraj Das <ddas@hortonworks.com<javascript:;>
> >
> > wrote:
> > > Hey James, couldn't we use the jira comments as a way to
> > > discuss/feedback, even though we use git repo?
> > >
> > > On Tue, Jan 28, 2014 at 10:47 PM, James Taylor <jamestaylor@apache.org<javascript:;>
> >
> > wrote:
> > >> 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
> >
> > --
> > CONFIDENTIALITY NOTICE
> > NOTICE: This message is intended for the use of the individual or entity
> to
> > which it is addressed and may contain information that is confidential,
> > privileged and exempt from disclosure under applicable law. If the reader
> > of this message is not the intended recipient, you are hereby notified
> that
> > any printing, copying, dissemination, distribution, disclosure or
> > forwarding of this communication is strictly prohibited. If you have
> > received this communication in error, please contact the sender
> immediately
> > and delete it from your system. Thank You.
> >
>
Re: best development methodology for Apache git?
Posted by Jesse Yates <je...@gmail.com>.
Git is just a source control system - it was github that lead to the
prevalence of the pull requests and merges.
Whatever we do for reviews, we basically need to use git like svn and fully
sync the repo each time, apply the patch, and then commit. Git hosting just
means ppl work in the same source control as the project and its easier to
do things like feature branches.
For reviews/discussion, Id recommend we do one of two things:
1. Do just what HBase does and post patches on Jiras, discuss there, and
take any extra discussion to review board. This makes it really easy to
follow for any downstream projects. However, review board only works on
trunk - patches on older versions tend to be a bit harder to review.
2. Use jiras for discussion and then do reviews on pull requests against
the apache github mirror. It can be a little out of date, but tends to be
pretty close. The advantage being that can have reviews more easily against
any branch. Once the review is good, the comitter would download the patch,
attach it to the jira (so downstream projects can keep track of the jiras
and their patches) and the commit it. I've heard of projects doing this,
but can't recall the exact names right now.
I'm leaning towards (2), but think either would work fine. Its just been a
pain in the past for HBase when reviewing large 0.94 patches to have to
manually review the patch, rather than use a really review tool; using pull
requests would solve this, but adds a little complication to the process
(though people still do pull requests against HBase sometimes, so maybe not
so hard to figure out?)
Just my $0.03
--j
PS we should also consider getting something like the HadoopQA bot going
for phoenix too
On Jan 28, 2014 11:10 PM, "Devaraj Das" <dd...@hortonworks.com> wrote:
> And there is reviewboard which is pretty widely used in HBase for the
> code review (and that works off git repo too)..
>
> On Tue, Jan 28, 2014 at 10:54 PM, Devaraj Das <dd...@hortonworks.com>
> wrote:
> > Hey James, couldn't we use the jira comments as a way to
> > discuss/feedback, even though we use git repo?
> >
> > On Tue, Jan 28, 2014 at 10:47 PM, James Taylor <ja...@apache.org>
> wrote:
> >> 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
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>
Re: best development methodology for Apache git?
Posted by Andrew Purtell <ap...@apache.org>.
To highlight what Devaraj says, actually Reviewboard (reviews.apache.org)
aka RB has good support for uploading Git generated diffs. I've found it
easier to do that than SVN diffs, so when preparing HBase patches for RB
I'll go through Git locally to get them there.
On Tue, Jan 28, 2014 at 11:09 PM, Devaraj Das <dd...@hortonworks.com> wrote:
> And there is reviewboard which is pretty widely used in HBase for the
> code review (and that works off git repo too)..
>
> On Tue, Jan 28, 2014 at 10:54 PM, Devaraj Das <dd...@hortonworks.com>
> wrote:
> > Hey James, couldn't we use the jira comments as a way to
> > discuss/feedback, even though we use git repo?
> >
> > On Tue, Jan 28, 2014 at 10:47 PM, James Taylor <ja...@apache.org>
> wrote:
> >> 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
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>
--
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>.
As a GUI tool for reviewing code line by line, Reviewboard is fine in place
of Gerrit in my opinion. Gerrit is interesting if you want to also set up a
workflow where the review tool itself gates commits into the master branch.
However, we have a separate process in the Hadoop parts of ASF land
("HadoopQA") which can stand in for that role, as Jesse mentioned.
On Wed, Jan 29, 2014 at 8:42 AM, James Taylor <ja...@apache.org>wrote:
> Gerrit sounds interesting. Sounds like infra dismissed it though. Will ask
> about this on the general list too.
> Thanks,
> James
>
> On Wednesday, January 29, 2014, Nick Dimiduk <nd...@gmail.com> wrote:
>
> > Hi James,
> >
> > I don't have any good recommendations for preserving your Github-based
> > community on the Apache infrastructure. Maybe our friends on other Apache
> > projects that have made the transition, such as Storm or Mesos, have
> > experience to share?
> >
> > Outside of Github, I've been very happy using Gerrit [0] for git-based
> code
> > review. It supports a workflow such that commits to the "central"
> > repository can only be performed via its web interface and only after the
> > necessary +1 has been received. This also lets you enforce different
> commit
> > policies, including a fast-forward-only workflow (ie, a SVN-like linear
> > commit history). I'm afraid I've never configured a public git
> repository,
> > nor Gerrit, so my advice ends there.
> >
> > There's this old ticket [1] which hasn't received much attention.
> >
> > Let me know if I can provide more concrete assistance.
> >
> > -n
> >
> > [0]: https://code.google.com/p/gerrit/
> > [1]: https://issues.apache.org/jira/browse/INFRA-2205
> >
> >
> > On Tue, Jan 28, 2014 at 11:09 PM, Devaraj Das <ddas@hortonworks.com
> <javascript:;>>
> > wrote:
> >
> > > And there is reviewboard which is pretty widely used in HBase for the
> > > code review (and that works off git repo too)..
> > >
> > > On Tue, Jan 28, 2014 at 10:54 PM, Devaraj Das <ddas@hortonworks.com
> <javascript:;>
> > >
> > > wrote:
> > > > Hey James, couldn't we use the jira comments as a way to
> > > > discuss/feedback, even though we use git repo?
> > > >
> > > > On Tue, Jan 28, 2014 at 10:47 PM, James Taylor <
> jamestaylor@apache.org<javascript:;>
> > >
> > > wrote:
> > > >> 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
> > >
> > > --
> > > CONFIDENTIALITY NOTICE
> > > NOTICE: This message is intended for the use of the individual or
> entity
> > to
> > > which it is addressed and may contain information that is confidential,
> > > privileged and exempt from disclosure under applicable law. If the
> reader
> > > of this message is not the intended recipient, you are hereby notified
> > that
> > > any printing, copying, dissemination, distribution, disclosure or
> > > forwarding of this communication is strictly prohibited. If you have
> > > received this communication in error, please contact the sender
> > immediately
> > > and delete it from your system. Thank You.
> > >
> >
>
--
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 Jesse Yates <je...@gmail.com>.
I've used gerrit in the past, and like it just fine, but no need to rock
the boat too much :)
HadoopQA is a jenkins job that monitors JIRA and looks for patches people
post. It then runs a bunch of tests on that patch (does it compile, does it
compile against hadoop2, does it pass all the unit tests, are the line
lengths under 100 chars, etc.) that basically acts as a gating mechanism to
checkin (which can be overriden if the committer wants to run the tests
locally, but that's rare). Its pretty nice to have once the velocity starts
picking up so committers dont need to spend as much time verifying each
patch (running all the tests, etc).
-------------------
Jesse Yates
@jesse_yates
jyates.github.com
On Wed, Jan 29, 2014 at 8:42 AM, James Taylor <ja...@apache.org>wrote:
> Gerrit sounds interesting. Sounds like infra dismissed it though. Will ask
> about this on the general list too.
> Thanks,
> James
>
> On Wednesday, January 29, 2014, Nick Dimiduk <nd...@gmail.com> wrote:
>
> > Hi James,
> >
> > I don't have any good recommendations for preserving your Github-based
> > community on the Apache infrastructure. Maybe our friends on other Apache
> > projects that have made the transition, such as Storm or Mesos, have
> > experience to share?
> >
> > Outside of Github, I've been very happy using Gerrit [0] for git-based
> code
> > review. It supports a workflow such that commits to the "central"
> > repository can only be performed via its web interface and only after the
> > necessary +1 has been received. This also lets you enforce different
> commit
> > policies, including a fast-forward-only workflow (ie, a SVN-like linear
> > commit history). I'm afraid I've never configured a public git
> repository,
> > nor Gerrit, so my advice ends there.
> >
> > There's this old ticket [1] which hasn't received much attention.
> >
> > Let me know if I can provide more concrete assistance.
> >
> > -n
> >
> > [0]: https://code.google.com/p/gerrit/
> > [1]: https://issues.apache.org/jira/browse/INFRA-2205
> >
> >
> > On Tue, Jan 28, 2014 at 11:09 PM, Devaraj Das <ddas@hortonworks.com
> <javascript:;>>
> > wrote:
> >
> > > And there is reviewboard which is pretty widely used in HBase for the
> > > code review (and that works off git repo too)..
> > >
> > > On Tue, Jan 28, 2014 at 10:54 PM, Devaraj Das <ddas@hortonworks.com
> <javascript:;>
> > >
> > > wrote:
> > > > Hey James, couldn't we use the jira comments as a way to
> > > > discuss/feedback, even though we use git repo?
> > > >
> > > > On Tue, Jan 28, 2014 at 10:47 PM, James Taylor <
> jamestaylor@apache.org<javascript:;>
> > >
> > > wrote:
> > > >> 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
> > >
> > > --
> > > CONFIDENTIALITY NOTICE
> > > NOTICE: This message is intended for the use of the individual or
> entity
> > to
> > > which it is addressed and may contain information that is confidential,
> > > privileged and exempt from disclosure under applicable law. If the
> reader
> > > of this message is not the intended recipient, you are hereby notified
> > that
> > > any printing, copying, dissemination, distribution, disclosure or
> > > forwarding of this communication is strictly prohibited. If you have
> > > received this communication in error, please contact the sender
> > immediately
> > > and delete it from your system. Thank You.
> > >
> >
>
Re: best development methodology for Apache git?
Posted by James Taylor <ja...@apache.org>.
Gerrit sounds interesting. Sounds like infra dismissed it though. Will ask
about this on the general list too.
Thanks,
James
On Wednesday, January 29, 2014, Nick Dimiduk <nd...@gmail.com> wrote:
> Hi James,
>
> I don't have any good recommendations for preserving your Github-based
> community on the Apache infrastructure. Maybe our friends on other Apache
> projects that have made the transition, such as Storm or Mesos, have
> experience to share?
>
> Outside of Github, I've been very happy using Gerrit [0] for git-based code
> review. It supports a workflow such that commits to the "central"
> repository can only be performed via its web interface and only after the
> necessary +1 has been received. This also lets you enforce different commit
> policies, including a fast-forward-only workflow (ie, a SVN-like linear
> commit history). I'm afraid I've never configured a public git repository,
> nor Gerrit, so my advice ends there.
>
> There's this old ticket [1] which hasn't received much attention.
>
> Let me know if I can provide more concrete assistance.
>
> -n
>
> [0]: https://code.google.com/p/gerrit/
> [1]: https://issues.apache.org/jira/browse/INFRA-2205
>
>
> On Tue, Jan 28, 2014 at 11:09 PM, Devaraj Das <ddas@hortonworks.com<javascript:;>>
> wrote:
>
> > And there is reviewboard which is pretty widely used in HBase for the
> > code review (and that works off git repo too)..
> >
> > On Tue, Jan 28, 2014 at 10:54 PM, Devaraj Das <ddas@hortonworks.com<javascript:;>
> >
> > wrote:
> > > Hey James, couldn't we use the jira comments as a way to
> > > discuss/feedback, even though we use git repo?
> > >
> > > On Tue, Jan 28, 2014 at 10:47 PM, James Taylor <jamestaylor@apache.org<javascript:;>
> >
> > wrote:
> > >> 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
> >
> > --
> > CONFIDENTIALITY NOTICE
> > NOTICE: This message is intended for the use of the individual or entity
> to
> > which it is addressed and may contain information that is confidential,
> > privileged and exempt from disclosure under applicable law. If the reader
> > of this message is not the intended recipient, you are hereby notified
> that
> > any printing, copying, dissemination, distribution, disclosure or
> > forwarding of this communication is strictly prohibited. If you have
> > received this communication in error, please contact the sender
> immediately
> > and delete it from your system. Thank You.
> >
>
Re: best development methodology for Apache git?
Posted by Nick Dimiduk <nd...@gmail.com>.
Hi James,
I don't have any good recommendations for preserving your Github-based
community on the Apache infrastructure. Maybe our friends on other Apache
projects that have made the transition, such as Storm or Mesos, have
experience to share?
Outside of Github, I've been very happy using Gerrit [0] for git-based code
review. It supports a workflow such that commits to the "central"
repository can only be performed via its web interface and only after the
necessary +1 has been received. This also lets you enforce different commit
policies, including a fast-forward-only workflow (ie, a SVN-like linear
commit history). I'm afraid I've never configured a public git repository,
nor Gerrit, so my advice ends there.
There's this old ticket [1] which hasn't received much attention.
Let me know if I can provide more concrete assistance.
-n
[0]: https://code.google.com/p/gerrit/
[1]: https://issues.apache.org/jira/browse/INFRA-2205
On Tue, Jan 28, 2014 at 11:09 PM, Devaraj Das <dd...@hortonworks.com> wrote:
> And there is reviewboard which is pretty widely used in HBase for the
> code review (and that works off git repo too)..
>
> On Tue, Jan 28, 2014 at 10:54 PM, Devaraj Das <dd...@hortonworks.com>
> wrote:
> > Hey James, couldn't we use the jira comments as a way to
> > discuss/feedback, even though we use git repo?
> >
> > On Tue, Jan 28, 2014 at 10:47 PM, James Taylor <ja...@apache.org>
> wrote:
> >> 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
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>
Re: best development methodology for Apache git?
Posted by Devaraj Das <dd...@hortonworks.com>.
And there is reviewboard which is pretty widely used in HBase for the
code review (and that works off git repo too)..
On Tue, Jan 28, 2014 at 10:54 PM, Devaraj Das <dd...@hortonworks.com> wrote:
> Hey James, couldn't we use the jira comments as a way to
> discuss/feedback, even though we use git repo?
>
> On Tue, Jan 28, 2014 at 10:47 PM, James Taylor <ja...@apache.org> wrote:
>> 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
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender immediately
and delete it from your system. Thank You.
Re: best development methodology for Apache git?
Posted by Devaraj Das <dd...@hortonworks.com>.
Hey James, couldn't we use the jira comments as a way to
discuss/feedback, even though we use git repo?
On Tue, Jan 28, 2014 at 10:47 PM, James Taylor <ja...@apache.org> wrote:
> 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
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender immediately
and delete it from your system. Thank You.
Re: best development methodology for Apache git?
Posted by Jesse Yates <je...@gmail.com>.
On Thu, Jan 30, 2014 at 5:03 PM, James Taylor <ja...@apache.org>wrote:
> In what format is the patch given to you? Is it (or can it be) a git-diff?
>
HBase supports both svn and git. We can just support git for phoenix
> 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)?
>
That's where reviewboard comes into play - easier highlighting, syntax
highlighting etc. But for small patches, obviously not necessary
>
> 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).
>
Generally HBase does this by putting the JIRA in the commit message. For
instance, from the 0.94 branch the git history looks like:
commit 9ed1abd3b79f3cf53d8917f5fda1c7b0f3dd479c
Author: Jonathan Hsieh <jm...@apache.org>
Date: Thu Jan 23 18:10:56 2014 +0000
HBASE-10401 [hbck] perform overlap group merges in parallel
>
> 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 Andrew Purtell <ap...@apache.org>.
On Thu, Jan 30, 2014 at 5:03 PM, James Taylor <ja...@apache.org>wrote:
> Using review board sounds promising if it can be driven off of the
> git-diff.
Yes
--
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 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)
Re: best development methodology for Apache git?
Posted by James Taylor <ja...@apache.org>.
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 James Taylor <ja...@apache.org>.
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
> > > > >
> > > >
> > >
> >
>
best development methodology for Apache git?
Posted by Nick Dimiduk <nd...@gmail.com>.
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 James Taylor <ja...@apache.org>.
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>.
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 <ja...@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 James Taylor <ja...@apache.org>.
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" <de...@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 lars hofhansl <la...@apache.org>.
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" <de...@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