[qmtest] API enhancements

[Stefan Seefeld]

Mark Mitchell wrote:
 > Stefan Seefeld wrote:
 >
 >> hi there,
 >>
 >> now that the release is out, may I bring up the issue
 >> of API enhancements in general and my suggested change
 >> for field attributes in extensions in particular ?
 >
 >
 > Yes, you may. :-)
 >
 >> Did anybody review it ? Beside breaking the attribute
 >> ordering (which, according to Nathaniel, didn't follow
 >> any specific requirement anyways) the change is fully
 >> backward compatible, yet it provides a more compact
 >> and clean way for declaring new extensions.
 >
 >
 > I looked briefly at the patch, but not in terribly much detail.  If you
 > will re-forward it to me, or point me at the URL on the online archives,
 > I will take a harder look.

Hmm, I can't seem to find the archives any more. Is there a link to
it from the qmtest home page ?
My suggestion ran under the subject "RFE concerning 'Extension' class".

 > We should definitely update the
 > documentation to explain how to use the new technique if we decide to
 > adopt it; I can't remember if your patch did that or not.

it did not, as I only supplied the patch in reply to Zack's request for
code to see how it would work. An actual working patch should indeed come
with some docs.

 > Full backwards compatible is an important criteria for test classes, but
 > if you've met that, that's not an issue.  For database classes, we can

I 'fixed' one test that failed, though the failure was due to some
assumptions concerning the ordering of attributes, which, according to
Nathaniel, isn't even specified (i.e. my impression was that this test
is in fact testing undocumented / unspecified behavior). If the ordering
should indeed by preserved I can certainly work out a way to preserve it
with the new technique and also provide some docs explaining what the
ordering is and why.

 > be a little more flexible; the API there is not quite as settled, and we
 > know there are probably going to be some changes there.

Phew :-). The Database API is in fact where I expect lots of potential users
to 'plug in' to adapt qmtest to their legacy systems, so this is definitely
where I'd be looking into for cleanup / clarifications.

 >> And, to put it into a broader context: what API
 >> change requests would be acceptable for you ? Only
 >> bug fixes ? Or some design cleanup, too ?
 >
 >
 > Design cleanup is OK, but backwards compatibility is paramound, and we
 > do have a heavy weight on the side of if-it-aint't-broken-don't-fix-it
 > in that any change does introduce risk.

Understood. What is qmtest's current user base ? Do they all use qmtest's
own databases ? Or do they extend them with their own classes and thus
depend on the actual API ?

 > As I mentioned before, we'd be particularly excited about new test
 > classes; that's what we think would be the best use of major effort.

I agree. You once pointed me to some additional code in another
module (qmtest_gcc et al.), which may be incorporated into the 'standard
tests / databases'. What are your plans for this code ?

Regards,
		Stefan