qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marnie McCormack <marnie.mccorm...@googlemail.com>
Subject Re: Web site triage
Date Tue, 03 Feb 2009 09:53:07 GMT
I'll try to explain better, with the caveat that what we do on Apache Qpid
is not terribly well documented for this stuff, so I'd imagine we all have
slightly differing assumptions here ....

On Mon, Feb 2, 2009 at 11:28 PM, Rafael Schloming <rafaels@redhat.com>wrote:

>  I'm not sure I fully understand what you're saying. My assertion is quite
>> simple. The Mx releases don't promise any sort of interoperability between
>> Mx and Mx+/-1. This makes QA for these releases comparatively easy since we
>> only need to test that we have a self consistent and working snapshot in
>> order to release.
The Java broker & client are tested with previous releases, I do this for
each release as part of an extensive set of testing - targetted at our
existing user community. So, one person's QA here isn't anothers I guess. I
also used ti test the .Net and the C++ client - but this is not now
possible, sadly. I do still test against builds of these clients I know
users are interop-ing with the Java Broker. (These users currently have no
migration path btw, but that's a whole other topic.)

>> As soon as we start introducing the notion of point releases, whether it's
>> something like 1.5, 1.6, or whether it's M4.0.1, there is an implied promise
>> of interoperability that most people will expect given the chosen release
>> numbering convention, and it's something that we don't currently test for at
>> all. In fact as far as I'm aware most qpid developers pretty freely make
>> code changes without worrying about backwards compatibility at all.
I'm definitely ambivalent on the numbering stuff (swerve) but
interoperability is tested, and does matter to the Java developers I work
most closely with. We should care very much about backwards compatibility,
and I know some of us do :-)

>> If what you are suggesting is that we need to start thinking about when
>> and how to provide higher levels of interoperability, then I do agree that
>> this is something that we need to address at some point and will certainly
>> need some careful thought, however I would still assert that this implies
>> more testing and therefore more work, so I'm confused at the idea that
>> introducing this sort of point release would make anything easier.
Don't have too much of a view on point releases per se, but we (I) do
already do interop testing and release compatibility testing on each & every
release. It takes time, but our users need it.

>> On the other hand if you're suggesting there is a specific piece of work
>> you'd like to fast-track to a released state (e.g. 0-10 support in the Java
>> broker), then I'd say we should discuss that concretely and figure out the
>> best way to handle it. For that case specifically I could certainly see
>> doing a component level release assuming we were clear up front about
>> exactly what interop testing we were/weren't doing, and we named the release
>> accordingly.
Yes, this is really the case I care about (see the Eclipse Management
Console release thread from 08). But I can also see that there is a real
case for smaller, simpler releases on a component schedule basis. I don't
think this should be a major problem.

Seems to me we need to make some statements about what we (as a team) do for
testing etc even if we're not doing it on Apache infra ? Maybe that'd help
us to have a common perspective. I'll pull some info together.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message