Qpid Release Process - Adopt HTTPD Process Or ....

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

All,

I'd like to propose that we take a little time to define our Qpid Release
process now, for use/expansion during the M2 release.

The Incubator docs provide HTTPD, Struts and Commons as good examples of
release process definitions.

I've had a read through of them, and I think the HTTPD definition is the
best starting point for us. I'm not suggesting we follow it slavishly, but
that we adopt the same style and amend the content as necessary.

Please have a look at:

http://httpd.apache.org/dev/release.html - for the HTTPD release process
definition

... and the Incubator release info:

http://incubator.apache.org/guides/releasemanagement.html#best-practice-prepare-documentation

Note that the incubator release guide is very patchy, in that lots of the
sections are heavily TODO'd.

Thoughts ? I felt we should discuss and then probably vote on a release
definition ...

Bfn,
Marnie

Re: Qpid Release Process - Adopt HTTPD Process Or ....

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

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

Re: Qpid Release Process - Adopt HTTPD Process Or ....

[Martin Ritchie <ri...@apache.org>]

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

Re: Qpid Release Process - Adopt HTTPD Process Or ....

[Rajith Attapattu <ra...@gmail.com>]

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

Re: Qpid Release Process - Adopt HTTPD Process Or ....

[Rajith Attapattu <ra...@gmail.com>]

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

Re: Qpid Release Process - Adopt HTTPD Process Or ....

[Robert Godfrey <ro...@gmail.com>]

On 19/04/07, Alan Conway <ac...@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

RE: Qpid Release Process - Adopt HTTPD Process Or ....

[Alan Conway <ac...@redhat.com>]

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.

Cheers,
alan.

RE: Qpid Release Process - Adopt HTTPD Process Or ....

[Tomas Restrepo <to...@devdeo.com>]

Marnie,

> http://httpd.apache.org/dev/release.html - for the HTTPD release
> process
> definition

Sounds like a reasonable process to me.

> 
> ... and the Incubator release info:
> 
> http://incubator.apache.org/guides/releasemanagement.html#best-
> practice-prepare-documentation

Yikes! Please don't :)

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. 

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?


Tomas Restrepo
http://www.winterdom.com/weblog/

Re: Qpid Release Process - Adopt HTTPD Process Or ....

[Alan Conway <ac...@redhat.com>]

On Thu, 2007-04-19 at 15:35 +0100, Marnie McCormack wrote:
> All,
> 
> I'd like to propose that we take a little time to define our Qpid Release
> process now, for use/expansion during the M2 release.

> 
> http://httpd.apache.org/dev/release.html - for the HTTPD release process
> definition

I like this process. If I were foolish enough to volunteer as a release
manager I'd adopt it wholesale (except for the part about testing qpid
as Apache's web server!) and tweak as we go. 

> http://incubator.apache.org/guides/releasemanagement.html#best-practice-prepare-documentation

This is a classic Apache process, I love it :)  I quote:
 Rules: 
 TODO: incubator rules 

I'd avoid (again, if I were foolish enough...) any temptation to write
long process docs, and stick to keeping notes of what actually happens
in this release so the next person can benefit. 

I'm not foolish enough to volunteer as RM, but evidently I am foolish
enough to enter the email discussion. Doh!

Cheers,
Alan.