That all makes perfect sense to me, Ken. Thanks for the update. -Steve
> -----Original Message----- > From: Ken Giusti [mailto:[email protected]] > Sent: Thursday, December 10, 2009 10:39 AM > To: [email protected] > 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" <[email protected]> wrote: > > > 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:[email protected] > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
