Folks, My overall concern is that this project doesn't have the bandwidth to adequately support two different management implementations. That's really the crux of the issue for me.
The current problems we've been dealing with come down to the fact that there's inadequate test coverage for dual use QMFv1 and QMFv2. The latest problem (QMFv2 updates from the broker being dropped by qmf.console) has been broken for a long time. We shipped this broken for several releases. Why? Inadequate test coverage. Most - if not all - of the python tests use QMFv1. Yet qpid-tools are now (mostly) based on QMFv2. I'm not even sure to what extent the QMF agent libraries are tested - perhaps not at all for the cmake builds. This results in partial test coverage of both implementations - neither implementation gets fully tested. In the end, we try to support both, but are not able to guarantee the level of quality our users deserve for either. We should be concentrating our efforts on one implementation, and making it the best we can. -K ----- Original Message ----- > From: "Gordon Sim" <g...@redhat.com> > To: users@qpid.apache.org > Cc: d...@qpid.apache.org > Sent: Monday, May 6, 2013 7:11:18 AM > Subject: Plans for QMF v1 and v2 (was Re: QMFv2 object update bug [WAS Re: > Questions from a novice]) > > On 05/03/2013 04:51 PM, Ken Giusti wrote: > > I want to know what the > > QPID project's plan is for QMFv1/v2 support in the C++ broker going > > forward. > > > > If the consensus is that a 1.x C++ broker is going to support both > > QMFv1 and QMFv2, then simply reverting all the changes I've made to > > qmf.console and reverting to the old behavior is probably the least > > risky move. > > > > On the other hand, if the consensus is to deprecate QMFv1 support > > prior to releasing a 1.0 C++ broker - or perhaps toss in the towel on > > QMFv2 - then the final fix for this needs to take that plan into > > account. > > > > So I'm going to call a discussion among the developers, proposing we > > vote on what QMF support a 1.x C++ broker will provide. > > I'd like to move the discussion to the user list as there are folks > there who may not be on dev list but would be impacted or might > otherwise have an opinion. I'm assuming everyone on the dev list is also > on the user list (if not you really should be :-) > > By way of a short introduction, Ken's question comes after a long thread > focused on some issues around the dual support of v1 and v2 of the QMF > protocol in the console.py python library for applications built to > manage/monitor the c++ broker. > > > Once that's decided, we can determine the most appropriate fix. > > > > As an aside - we've talked a lot about preserving behavior and > > functionality across 0.X releases in this thread. While nobody wants > > to gratuitously break stuff, this project has reserved the right to > > remove and change functionality between 0.x releases in order to fix > > bugs and provide new features. Things may be different once we get > > to 1.x, but for 0.x, this has been the case. > > For my part, I am in favour of removing QMFv1 support, if necessary > providing some sort of adapter or plugin to deal with any use cases for > which this might prove problematic. I think QMFv2 is now firmly > established as the current management mechanism for the c++ broker. > > Ultimately I also think we should be starting to think about an AMQP 1.0 > based management standard and how we would transition to that. That is > however a larger question that shouldn't hold up the immediate decision > regarding QMFv1 though it may inform it a little. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > > -- -K --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
