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.

-- 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]

Reply via email to