Qpid Release Process - Definition Added

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

Hi All,

I have now amended and added the HTTPD style info to our Qpid Release Page:

http://cwiki.apache.org/confluence/display/qpid/QpidReleaseProcess

There are a few bits I'm not sure about - mainly in bold near the bottom.
Rajith et al - please do feel free to edit/clarify/etc !

We do, however, need to discuss the classification of release on this list
imho and vote on definitions ?

Hth,
Regards,
Marnie


On 4/23/07, Marnie McCormack <ma...@googlemail.com> wrote:
>
> Hi All,
>
> Playing slight catch up, apologies.
>
> So, a few comments on the various posts on this thread ....
>
> 1. Completely agree with Alan & Rob's comment on the goal of M2 being 0-8
> interop, as far as we can manage it ! I think we should correctly have
> modest goals for M2 and not seek to make it perfrect, but a useful milestone
> release which gets hitherto unreleased components out there and provides a
> good build for users, far more feature rich than M1 !
>
> 2. Re Rajith's point about M1 being fairly close to the HTTPD process -
> yes, and wasn't my intent to make any major changes just to get our approach
> doc'd in the interests of transparency for everyone and to move our project
> forward in incubation terms ! If no-one objects, I'll create a starter
> release process page with something pretty close to the HTTPD docs tomorrow
> and people can discuss/edit as we go along ?
>
> 3. Tomas - hoping you saw the vote thread which has a summary of the
> components we voted to release for M2 ? Personally (my fault) I doubt we
> really want to put Ruby out there (for maturity reasons) but the votes were
> in favour so had to go with that. (We can perhaps revisit if we find it
> problematic as we go along building M2).
>
> 4. Java JIRAs for M2 - I have reviewed all the Java JIRAs marked as for M2
> and thus far only left in scope those that need doing (have discussed with
> the reporters/assignees as I went along where not clear). Happy for people
> to review and amend if anyone disagrees with my assessments though :-)
>
> Phew. All that and chicken pox in our house this week :-(
>
> Anyhow, more tomorrow !
>
> Regards,
> Marnie
>
>
> On 4/20/07, Martin Ritchie <ri...@apache.org> wrote:
> >
> > On 19/04/07, Rajith Attapattu <ra...@gmail.com> wrote:
> > > Alan has volunteered to help with the  C++ release and Rafi has
> > offered to
> > > help with the python/ruby clients.
> > > Can Martin volunteer for the java broker/client ?
> > > I am not familliar with the M2 releated JIRA's as most of my work has
> > been
> > > on branches. So if Martin or Rupert can help sort which JIRA's are
> > priority
> > > to M2 and then fix them, I really appreciate that. I see that Marnie
> > has
> > > already sorted through the JIRA's.
> > >
> > > Can Alan, Rafi and Martin/Rupert update the release page with action
> > > items/time frames?? If so then we can start working on the overall
> > release
> > > plan/schedule.
> > >
> > > Regards,
> > >
> > > Rajith.
> > >
> > > On 4/19/07, Rajith Attapattu <ra...@gmail.com> wrote:
> > > >
> > > > Marnie,
> > > >
> > > > The current release process (what we did for M1) was more or less
> > the
> > > > HTTPD release process.
> > > > Well......maybe we cut a few corners here and there, but I think we
> > did
> > > > ok.
> > > > So +1 for following the process properly :)
> > > >
> > > > Rajith
> > > >
> > > > On 4/19/07, Robert Godfrey <ro...@gmail.com> wrote:
> > > > >
> > > > > On 19/04/07, Alan Conway < aconway@redhat.com> wrote:
> > > > > >
> > > > > > On Thu, 2007-04-19 at 10:44 -0500, Tomas Restrepo wrote:
> > > > > > > If I may offer a humble suggestion here: Could we please first
> > agree
> > > > > on
> > > > > > what
> > > > > > > to release and what may constitute a good reason to plan a
> > release?
> > > > > My
> > > > > > point
> > > > > > > here is that it would be really nice if the entire project was
> >
> > > > > working
> > > > > > > alongside the same plan. Right now we have the C++ code going
> > in one
> > > > >
> > > > > > > direction, the Java code going into a somewhat different
> > direction,
> > > > > the
> > > > > > .NET
> > > > > > > code playing catchup, and I don't even know what the python
> > and ruby
> > > > > > code
> > > > > > > bases are.
> > > > > >
> > > > > > I think that's one of the key goals of the M2 release. M2
> > represents
> > > > > the
> > > > > > last time all the projects *were* in a consistent interoperable
> > state,
> > > > > > so it's a valuable thing to get out there.
> > > > > >
> > > > > > > For example, it would seem sensible, while the protocol spec
> > is in
> > > > > flux,
> > > > > > to
> > > > > > > align one way or another the project releases with the
> > protocol
> > > > > > releases.
> > > > > > > That is to say, if we define protocol version Y as being of
> > interest
> > > > > to
> > > > > > the
> > > > > > > project, either target it all, or don't target it at all.
> > Otherwise,
> > > > > > getting
> > > > > > > the interop in place just among our different code bases will
> > be too
> > > > > > > painful, not to even speak of interoping with other protocol
> > > > > > > implementations.
> > > > > > >
> > > > > > > Any comments?
> > > > > >
> > > > > > We're in a bit of a discombobulated state right now as you point
> > out.
> > > > > I
> > > > > > would say that M3 (or whatever the next major release is called)
> > > > > should
> > > > > > aim to get us back in sync with all projects on the same major
> > > > > protocol
> > > > > > version. I used to think this would be 0-9, but it looks like we
> > may
> > > > > > have to wait for 0-10. Its not clear now how far away that is,
> > if it
> > > > > > doesn't happen soon we may need to find another way to reconnect
> > the
> > > > > > projects. I'm in two minds about making C++ bilingual 0-8, 0-9 -
> > I'll
> > > > > > wait till after the AMQP FTF and see how far away 0-10 looks
> > before I
> > > > > > reconsider the question.
> > > > >
> > > > >
> > > > > M2 should be "all brokers and clients interoperable at AMQP0-8",
> > plus
> > > > > Java
> > > > > Broker - Java client JMS TCK compatability (requires Qpid
> > "extensions"
> > > > > to
> > > > > AMQP).
> > > > >
> > > > > AMQP0-9 (without the WIP additions) may be very easy to implement
> > and I
> > > > > think that is what OpenAMQ has achieved.  However we may not see
> > much
> > > > > value
> > > > > in this.
> > > > >
> > > > > AMQP0-10 will liklely be a fairly major set of changes.  As Alan
> > aludes
> > > > > to
> > > > > there is an AMQP face to face meeting next week at which the AMQP
> > > > > working
> > > > > group will try to come to agreements on aspects of 0-10 as well as
> > a
> > > > > scope
> > > > > for 0-11.
> > > > >
> > > > > One of the things I would like to see defined is the degree to
> > which
> > > > > (post
> > > > > 1-0) versions of the protocol may differ within a major
> > release.  The
> > > > > amount
> > > > > of change which we will have to accomodate will influence how we
> > design
> > > > > our
> > > > > multi-version support (post 1-0 we should support prior versions
> > to the
> > > > > one
> > > > > we claim to support, prior to 1-0 we are not expected to make that
> > > > > guarantee).
> > > > >
> > > > > -- Rob
> >
> > I should have some time to do that now.
> >
> > --
> > Martin Ritchie
> >
>
>