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 +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-subscr...@qpid.apache.org --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
