Re: Web site triage

[Rafael Schloming <ra...@redhat.com>]

Marnie McCormack wrote:
> I'd put the opposite view forward - we are currently unable to avoid doing
> releases with non-interop-ing components and are also duty bound to test
> against old broker/client releases (we do this for each release).
> 
> Thus I think component releases should not present a problem - we could, of
> course, introduce a quality gateway that the release manager would own i.e.
> version blah of this component has been tested against versions 1,2,3 of
> other components A,B,C.
> 
> For example, if the 0-10 work on the Java broker got committed tomorrow we'd
> be mad not to release it asap.
> 
> It's probably unreasonable to force all the components, with widely
> differing roadmpas, to conform to one release schedule.
> 
> It'd surely (please god) be simpler to get our releases out with a single or
> smaller set of component parts.

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.

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.

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.

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.

--Rafael

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

Re: Web site triage

[Marnie McCormack <ma...@googlemail.com>]

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 <ra...@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.

Regards,
Marnie

>
>