Re: [QMF] public github repo for QMFv2 api work
Hi all - thanks for all the feedback. I didn't explain my main motivation for setting up the github repo: backups. I wanted some safe place to put the code in case my dog eats my laptop (again). Getting scm functionality, and doing it all in the open in a way that people can easily play with it (without patches, etc) are important too. But let me be clear on a couple of points: 1) I'll definitely submit all the code as patches through Jira. I've opened https://issues.apache.org/jira/browse/QPID-2261 for this. But since this stuff is changing quite rapidly, it only makes sense to submit patches when stuff becomes stable. 2) I'm the only person who can push to that github repo. Anyone can pull and try out the code, but only I can pull submissions into it. If people want to submit patches (who are not already qpid committers), I'll have them post those patches to the Jira, and grant the license properly. I'd like to see a branch for qmfv2 in svn, if possible - that would keep the size of the patches submitted via the jira small. Opinions? thanks, -K -K - Andrew Stitcher astitc...@redhat.com wrote: On Wed, 2009-12-09 at 20:25 +, 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-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: [QMF] public github repo for QMFv2 api work
That all makes perfect sense to me, Ken. Thanks for the update. -Steve -Original Message- From: Ken Giusti [mailto:kgiu...@redhat.com] Sent: Thursday, December 10, 2009 10:39 AM To: dev@qpid.apache.org Subject: Re: [QMF] public github repo for QMFv2 api work Hi all - thanks for all the feedback. I didn't explain my main motivation for setting up the github repo: backups. I wanted some safe place to put the code in case my dog eats my laptop (again). Getting scm functionality, and doing it all in the open in a way that people can easily play with it (without patches, etc) are important too. But let me be clear on a couple of points: 1) I'll definitely submit all the code as patches through Jira. I've opened https://issues.apache.org/jira/browse/QPID-2261 for this. But since this stuff is changing quite rapidly, it only makes sense to submit patches when stuff becomes stable. 2) I'm the only person who can push to that github repo. Anyone can pull and try out the code, but only I can pull submissions into it. If people want to submit patches (who are not already qpid committers), I'll have them post those patches to the Jira, and grant the license properly. I'd like to see a branch for qmfv2 in svn, if possible - that would keep the size of the patches submitted via the jira small. Opinions? thanks, -K -K - Andrew Stitcher astitc...@redhat.com wrote: On Wed, 2009-12-09 at 20:25 +, 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-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
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? Thanks, Robert - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [QMF] public github repo for QMFv2 api work
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
2009/12/9 Carl Trieloff cctriel...@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-subscr...@qpid.apache.org
RE: [QMF] public github repo for QMFv2 api work
-Original Message- From: Robert Greig [mailto:robert.j.gr...@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-subscr...@qpid.apache.org
Re: [QMF] public github repo for QMFv2 api work
Robert Greig wrote: 2009/12/9 Carl Trieloff cctriel...@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
On Wed, 2009-12-09 at 20:25 +, 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-subscr...@qpid.apache.org
