qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Giusti <kgiu...@redhat.com>
Subject Re: [QMF] public github repo for QMFv2 api work
Date Thu, 10 Dec 2009 15:39:09 GMT

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" <astitcher@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-subscribe@qpid.apache.org

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org


Mime
View raw message