You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Ken Giusti <kg...@redhat.com> on 2009/12/09 14:59:58 UTC
[QMF] public github repo for QMFv2 api work
Hi all,
Just fyi - I've set up a public git repo at github so I can develop the QMFv2 API code publicly. I've created this because I am not a committer, but I want this stuff available to all during development.
git://github.com/kgiusti/qpid.git
This repo is based on the apache qpid trunk repo on github.
thanks,
-K
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [QMF] public github repo for QMFv2 api work
Posted by Carl Trieloff <cc...@redhat.com>.
Robert Greig wrote:
> 2009/12/9 Carl Trieloff <cc...@redhat.com>:
>
>
>> In the ASF, unfortunately to give commit rights to anything we need to get
>> through the
>> committer nomination and vote process.
>>
>
> Do you (or anyone else) know what the rationale for this is?
Main thing is infra does not want to deal with high churn on accounts
etc of people that
may not stick around. So for net new committers for apache this is the
process.
Carl.
Re: [QMF] public github repo for QMFv2 api work
Posted by Robert Greig <ro...@gmail.com>.
2009/12/9 Carl Trieloff <cc...@redhat.com>:
> In the ASF, unfortunately to give commit rights to anything we need to get
> through the
> committer nomination and vote process.
Do you (or anyone else) know what the rationale for this is?
Thanks,
Robert
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [QMF] public github repo for QMFv2 api work
Posted by Carl Trieloff <cc...@redhat.com>.
Robert Greig wrote:
>> I think the safest option is to expose your work through a series of JIRA's.
>> If we need to make the code available immediately and/or collaborate
>> with others we could create a branch.
>> You could work off the branch and then Ted could apply the patches as
>> an when they are made available.
>>
>
> I think this approach - creating patches and applying them to Jira is
> very poor for several reasons:
>
> 1) it is a pain to create patches and attach them to jira (at least I think so)
> 2) it is a pain for a reviewer to extract them from the jira, review and commit
> 3) because of the above it encourages the large code drops that we
> have discussed recently
>
> Is it not possible for us to create a branch and give Ken commit
> rights *only* to the branch? As long as he has signed the CLA that
> should be much simpler all round since someone just has to merge - Ken
> could use Jiras or the mailing list to prompt a buddy to review and
> merge at appropriate points.
>
> For the rest of us who are interested in what is going on but not so
> interested that we are willing to mess about with patches from Jira
> this would be better too.
>
> Steve, as someone who had to go through the process of jiras
> relatively recently, would that have been easier for you?
In the ASF, unfortunately to give commit rights to anything we need to
get through the
committer nomination and vote process.
He can hold a GIT and then update JIRA with patches as he goes and
someone then
has to take the patches from from JIRA due to lic issues on the JIRA
click through.
best if for new people to be visible on the project and lists to get to
committership.
Carl.
RE: [QMF] public github repo for QMFv2 api work
Posted by Robbie Gemmell <ro...@gmail.com>.
As an even more recent committer than Steve, ill chime in too.
I don't think anyone would argue against it being easiest to have commit
rights from the get go, even if only to a branch. Attaching patches to JIRAs
does get a bit tiresome if they aren't picked up for a while, or if you
start tripping over previous patches while working on unrelated issues in
similar areas, meaning that they need to be applied in a particular order
etc. I was working back and forth all over the place and this still only
happened a couple times, Ken shouldn't have as much of an issue with that as
all the work is contained on the same issue towards the same goal.
Also, that's mostly only an issue when using SVN locally... Git really does
make the world a better place, especially when tracking a repository you
don't have commit rights to, as it's easy to maintain your own local (or
remote via git-hub) commits and branches. And if you are working on the same
issue in the same area all the time anyway, a sequential nature of patches
will emerge. I think a lot of the existing committers are using Git locally
now too, so it would be easy for Ken to generate a series of patches with
git-format-patch and attach them in a zip to JIRA, and then it's a similarly
simple one-off Git command for a reviewer to apply all of them at once. Then
once any of Kens patches were applied in SVN, Git will figure that out
easily.
So, yes it would have been easier...but tracking trunk is not necessarily
that big a hassle to someone using Git anyway. Also, the entire process sort
of helps with integration into the project and workflow required to be an
apache committer...and damnit, Steve has just beaten me as I typed way too
much lol ;)
Robbie
> -----Original Message-----
> From: Robert Greig [mailto:robert.j.greig@gmail.com]
> Sent: 09 December 2009 20:25
> To: dev@qpid.apache.org
> Subject: Re: [QMF] public github repo for QMFv2 api work
>
> Is it not possible for us to create a branch and give Ken commit
> rights *only* to the branch? As long as he has signed the CLA that
> should be much simpler all round since someone just has to merge - Ken
> could use Jiras or the mailing list to prompt a buddy to review and
> merge at appropriate points.
>
> For the rest of us who are interested in what is going on but not so
> interested that we are willing to mess about with patches from Jira
> this would be better too.
>
> Steve, as someone who had to go through the process of jiras
> relatively recently, would that have been easier for you?
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: [QMF] public github repo for QMFv2 api work
Posted by Steve Huston <sh...@riverace.com>.
> -----Original Message-----
> From: Robert Greig [mailto:robert.j.greig@gmail.com]
> Sent: Wednesday, December 09, 2009 3:25 PM
> To: dev@qpid.apache.org
> Subject: Re: [QMF] public github repo for QMFv2 api work
>
>
> > I think the safest option is to expose your work through a
> series of JIRA's.
> > If we need to make the code available immediately and/or
collaborate
> > with others we could create a branch.
> > You could work off the branch and then Ted could apply the
> patches as
> > an when they are made available.
>
> I think this approach - creating patches and applying them to Jira
is
> very poor for several reasons:
>
> 1) it is a pain to create patches and attach them to jira (at
> least I think so)
> 2) it is a pain for a reviewer to extract them from the jira,
> review and commit
> 3) because of the above it encourages the large code drops that we
> have discussed recently
>
> Is it not possible for us to create a branch and give Ken commit
> rights *only* to the branch? As long as he has signed the CLA that
> should be much simpler all round since someone just has to merge -
Ken
> could use Jiras or the mailing list to prompt a buddy to review and
> merge at appropriate points.
>
> For the rest of us who are interested in what is going on but not so
> interested that we are willing to mess about with patches from Jira
> this would be better too.
>
> Steve, as someone who had to go through the process of jiras
> relatively recently, would that have been easier for you?
I think Carl's comments made this moot, but...
Yes, it would have been easier for me at the time. But it would have
been worse in the end. Having to do patches and jiras had the
benefits:
- Something to notify the community that there was something to
review. Not being familiar with the personnel at the time, this was
what got me some answers quickly on who was most related to what I
needed to know.
- Got me into the Apache Way quicker and I think it has helped in the
long run.
-Steve
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [QMF] public github repo for QMFv2 api work
Posted by Andrew Stitcher <as...@redhat.com>.
On Wed, 2009-12-09 at 20:25 +0000, Robert Greig wrote:
> > I think the safest option is to expose your work through a series of JIRA's.
> > If we need to make the code available immediately and/or collaborate
> > with others we could create a branch.
> > You could work off the branch and then Ted could apply the patches as
> > an when they are made available.
>
> I think this approach - creating patches and applying them to Jira is
> very poor for several reasons:
>
> 1) it is a pain to create patches and attach them to jira (at least I think so)
> 2) it is a pain for a reviewer to extract them from the jira, review and commit
> 3) because of the above it encourages the large code drops that we
> have discussed recently
I'd say that using git is pretty good for the purposes of working in the
open conveniently but still producing patches attached to jiras.
The alternative would be for Ken to work in private producing patches,
at the end of the process.
Surely working in the open based on the git.apache.org/qpid repo and
producing git patches relative to that using git format-patch will
ultimately make it very easy for anyone to apply the patches with no
ambiguity, and in the meantime allow us to also pull from his work.
Andrew
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [QMF] public github repo for QMFv2 api work
Posted by Robert Greig <ro...@gmail.com>.
> I think the safest option is to expose your work through a series of JIRA's.
> If we need to make the code available immediately and/or collaborate
> with others we could create a branch.
> You could work off the branch and then Ted could apply the patches as
> an when they are made available.
I think this approach - creating patches and applying them to Jira is
very poor for several reasons:
1) it is a pain to create patches and attach them to jira (at least I think so)
2) it is a pain for a reviewer to extract them from the jira, review and commit
3) because of the above it encourages the large code drops that we
have discussed recently
Is it not possible for us to create a branch and give Ken commit
rights *only* to the branch? As long as he has signed the CLA that
should be much simpler all round since someone just has to merge - Ken
could use Jiras or the mailing list to prompt a buddy to review and
merge at appropriate points.
For the rest of us who are interested in what is going on but not so
interested that we are willing to mess about with patches from Jira
this would be better too.
Steve, as someone who had to go through the process of jiras
relatively recently, would that have been easier for you?
Thanks,
Robert
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [QMF] public github repo for QMFv2 api work
Posted by Rajith Attapattu <ra...@gmail.com>.
Ken I appreciate your effort in making the development process as open
as possible.
But I agree with Steve about the licensing issues.
I think the safest option is to expose your work through a series of JIRA's.
If we need to make the code available immediately and/or collaborate
with others we could create a branch.
You could work off the branch and then Ted could apply the patches as
an when they are made available.
Rajith
On Wed, Dec 9, 2009 at 11:15 AM, Steve Huston <sh...@riverace.com> wrote:
> Hi Ken,
>
>> -----Original Message-----
>> From: Ken Giusti [mailto:kgiusti@redhat.com]
>> Sent: Wednesday, December 09, 2009 9:00 AM
>> To: dev
>> Subject: [QMF] public github repo for QMFv2 api work
>>
>>
>> Hi all,
>>
>> Just fyi - I've set up a public git repo at github so I can
>> develop the QMFv2 API code publicly. I've created this
>> because I am not a committer, but I want this stuff available
>> to all during development.
>>
>> git://github.com/kgiusti/qpid.git
>>
>> This repo is based on the apache qpid trunk repo on github.
>
> I was in a similar situation when I did the initial Windows port a
> while back, and I went the git route too. I was advised by more senior
> Apache people that it's not a good idea because it opens the door to
> code getting in which hasn't been through the JIRA's "I license this
> to Apache" check-off. If someone without a CLA drops code into your
> git repo, then that goes into the svn repo, that's a big problem.
>
> FWIW,
>
> -Steve
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: [QMF] public github repo for QMFv2 api work
Posted by Steve Huston <sh...@riverace.com>.
Hi Ken,
> -----Original Message-----
> From: Ken Giusti [mailto:kgiusti@redhat.com]
> Sent: Wednesday, December 09, 2009 9:00 AM
> To: dev
> Subject: [QMF] public github repo for QMFv2 api work
>
>
> Hi all,
>
> Just fyi - I've set up a public git repo at github so I can
> develop the QMFv2 API code publicly. I've created this
> because I am not a committer, but I want this stuff available
> to all during development.
>
> git://github.com/kgiusti/qpid.git
>
> This repo is based on the apache qpid trunk repo on github.
I was in a similar situation when I did the initial Windows port a
while back, and I went the git route too. I was advised by more senior
Apache people that it's not a good idea because it opens the door to
code getting in which hasn't been through the JIRA's "I license this
to Apache" check-off. If someone without a CLA drops code into your
git repo, then that goes into the svn repo, that's a big problem.
FWIW,
-Steve
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org