Picking Github also means picking a more decentralized collaboration model where there is no 'owner' or group of owners that folks have to get blessing from to start contributing in a meaningful way. Any one can fork at any time and contribute. Worthy contributions will be merged by the other forks. That aspect also increases the idea of vendor/organization independence.
On Fri, Jun 11, 2010 at 10:15 AM, Alan Conway <acon...@redhat.com> wrote: > On 06/10/2010 01:36 PM, Bruce Snyder wrote: >> >> On Thu, Jun 10, 2010 at 5:25 PM, Bruce Snyder<bruce.sny...@gmail.com> >> wrote: >>> >>> On Thu, Jun 10, 2010 at 5:17 PM, Lahiru Gunathilake<glah...@gmail.com> >>> wrote: >>>>> >>>>> Hi Bruce, >>>> >>>> One consideration that we identified is that this work will probably >>>>> >>>>> need to take place outside of the ASF so that non-ASF folks can >>>>> participate (we each agreed that Github would be suitable). >>>>> >>>> -1 ! >>>> I do not think this is a good approach to do this and we can always >>>> start >>>> this inside ASF as a sub project of Qpid and ask Non ASF folks be ASF >>>> folks >>>> ! >>> >>> I disagree with hosting it under either the Qpid or ActiveMQ projects. >>> This effort is separate from ActiveMQ or Qpid projects. It's focused >>> strictly on AMQP 1.0 protocol handling. In a perfect world this effort >>> would exist at the AMQP working group's website, but the working group >>> is strictly against the creation and maintenance of any reference >>> implementations. I suppose one other option is the creation of a new >>> project at the ASF, but the only way to do that is via the Incubator >>> and I'm not sure I want the encumbrances that that brings. >> >> I just re-read the Qpid website for a description of the project. The >> most meaningful info I found is here: >> >> http://qpid.apache.org/amqp-compatibility.html >> >> So Qpid seems to be focused on its broker and client *implementations* >> of the spec. The effort I proposed would be focused on a library to be >> used for building AMQP 1.0 clients, not a broker-specific client >> implementation. Like I said previously, the best analogy for this >> effort is to the Apache Commons HTTP Client and the library it >> provides for the HTTP spec. Many folks use the HTTP Client on which to >> build apps and custom HTTP clients. This effort will provide a similar >> spec-focused client library for AMQP 1.0. >> >> So having the project separate from any broker implementation is the >> ideal. >> > > Just read this thread and it makes perfect sense to me that the new project > should not be embedded in ActiveMQ or Qpid. > But that doesn't mean it shouldn't be an apache project. > > Paul Fremantle said: >> >> We could set this up as a labs project. http://labs.apache.org/ >> >> I think that meets your requirements as being independent from >> ActiveMQ and QPid. From there it could go via incubation and become >> its own TLP. > > IMO making it a new Apache project makes sense since so many of the > interested parties (ActiveMQ and qpid) are already involved in Apache. For > those not involved in Apache projects, Apache is still a respectable place > to host a project. I see no reason why e.g. RabbitMQ folks wouldn't > contribute to an independent AMQP client project hosted at Apache. > > I've got nothing against github but I'd prefer not to multiply the number of > organizations involved without good reason. The only reason I've seen > proposed for github is independence from qpid/ActiveMQ, and a new Apache > project would satisfy this requirement just as well. > > > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > > -- Regards, Hiram Blog: http://hiramchirino.com Open Source SOA http://fusesource.com/ --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
