On Thu, Jul 12, 2012 at 2:44 PM, Rob Godfrey <[email protected]> wrote: > On 12 July 2012 20:28, Rajith Attapattu <[email protected]> wrote: >> On Thu, Jul 12, 2012 at 1:28 PM, Gordon Sim <[email protected]> wrote: >>> On 07/12/2012 06:14 PM, Rajith Attapattu wrote: >>>> >>>> I think we should also consider a separate JIRA instance to go with >>>> this >>> >>> >>> why? >> >> I was thinking about having a single place to report all "AMQP" related >> issues. >> This includes proton, messenger API and the messaging API. >> IMO It makes sense to have the messaging API under the proton project as >> well. >> So perhaps something like "qpid-amqp" is a more appropriate name than >> qpid-proton . Good for google search too ;) >> Both 'amqp' and 'qpid' have brand value, so why not make use of it ? > > I agree in the case of the mailing list. I think for JIRA we should > tie the projects to the actual release units (the things with version > numbers). This may change over time as the whole Qpid project evolves, > but right now that would mean one for all the components that we > currently release - the existing "QPID-" JIRA, and one for the stuff > under /qpid/proton in subversion (which I think makes sense to label > "PROTON-" in JIRA). > > As the project evolves and the release structure changes it may well > make sense to move to the set you suggest... or we may discover that a > completely different grouping makes sense. Trying to anticipate now > what our long term release artefacts are seems premature. What we > need *now* is a way to raise issues against the code that lives in > /qpid/proton and to label them into numbered releases in a logical > way.
Agreed. I was thinking a bit too far ahead. > -- Rob > > > >> >> Apologies if I go off topic here, but thought it was somewhat relevant >> to this discussion. >> I think the following components could be thought of as sub projects >> and have independent release cycles. >> >> 1. AMQP libraries + client APIs >> 2. Messaging Brokers >> 3. Management tools (QMF and other tools) >> 4. JMS, WCF and other domain specific clients. >> >> Once we implement WCF and JMS properly I don't really see a point in >> releasing them with the brokers or the rest of the clients. >> >> Rajith >> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
