On 27 March 2013 14:26, Gordon Sim <g...@redhat.com> wrote: > On 03/26/2013 08:06 PM, Rob Godfrey wrote: > >> I think in general we suffer because we haven't properly thought about >> what >> our "components" are and what it means to be a component. Proton is a >> component and has a sensible location in our repo, and its own release >> cycle and JIRA project. I tend to think long term other components (or >> groups of components) should follow this pattern. >> > > Good points. I personally am not convinced that each component needs its > own JIRA, or its own release cycle. However I do agree that our current > source layout and release artefacts do not align well with logical > components.
I don't think there need to be hard and fast rules about this. Having a separate release cycle is difficult when using the same JIRA system as the releases are JIRA project wide. There are components that will probably naturally synchronize their release cycles and as such that would be fine... OTOH there's definitely a case to be made of not artificially trying to synchronize releases... Our time based release schedule can lead to somewhat > I would also concede the exact set of components is not as clear as it > needs to be. > > So, other than proton, what are the components? I think the key property > of a component is that it is self-contained and independent of any other > particular component. The components that seem most obvious to me at > present are: > > * JMS client[1] > * qpid::messaging client in c++ > * qpid.messaging client in python[2] > * c++ broker > * java broker > > There is probably a component or two among the various management tools. > Some are very toed to one broker, which to some extent violates my rule. > Probably the clearest component here is Fraser's new GUI management tool, > since that can now be used against either broker. The command line tools > for c++ broker[3] are perhaps best viewed as a sub-component of the c++ > broker for now (though some of them may now work against the java broker > when Fraser's adapter is in place). > > The various swig and c# wrappers around the qpid::messaging c++ client are > in my view sub components of the c++ client at present. > > So one question I would have is whether two implementations of the same API should not actually be the same component... Should we not just have a Qpid JMS component that currently has two released artefacts? Similarly the Qpid Messaging API may have a pure python implementation and the C++/Swigged versions. This seems analogous to how Proton is working with both a Java and a C implementation. > I am not keen to lump changes to the svn, build and packaging in with > changes to the website. That is exactly why we never make progress because > the scope outgrows the available resource. We can get the website structure > and layout right, map it to the existing 'broken' structures and then as a > separate step(s) tackle any changes to structure. I don't oppose any > changes there, I just don't want the website update to be dependent on > their completion. As Rob said earlier, having a new website in place for > the 0.22 would be really great. > > I agree i don't want to hold up the website change for an svn reorganisation, but if we are looking to do an svn reorganisation the obvious time to do it would be immediately after a release. -- Rob --Gordon. > > [1] At present we sort of have two of these, but I think long term there > should be only one, even if it has quite divergent codepaths for different > versions of the protocol. Alternatively we could have one for AMQP 1.0 and > another tucked away somewhere for legacy versions). > > [2] Though we need to decide what we are doing for AMQP 1.0 here. If there > is insufficient resource available to convert the native client to 1.0, we > could consider the python swig wrapper round the c++ as the alternative > for transition to 1.0. > > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > users-unsubscribe@qpid.apache.**org<users-unsubscr...@qpid.apache.org> > For additional commands, e-mail: users-h...@qpid.apache.org > >
