qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rupert Smith" <rupertlssm...@googlemail.com>
Subject Re: Qpid M2 Branching / C++ 0.9 Merging
Date Wed, 07 Mar 2007 15:24:28 GMT
What If:

We find that the M2 branch needs a *lot* of work to get it in shape to
release? This will mean a lot of merging, getting increasingly
difficult as trunk diverges away in the 0.9 direction. Also, isn't it
a good idea to bring trunk up to production quality every now and
again? I agree with Martin that a release branch should ideally only
have small bug fixes applied to it. Are we certain that trunk is
currently in that shape? Presumably M2 and subsequent bug fixes is
what our customers will go into production with?

However,

> Define a point in the very near future (5 days or less) when we cut the
> branch for M2.

5 days sounds like long enough to me. Or maybe 7?

I got the impression from Marnies original mail that the vote wasn't
for release now, but for 'yes we are going to release, but there is
still a lot to do...'.

Rupert

On 3/7/07, Robert Godfrey <rob.j.godfrey@gmail.com> wrote:
> I share your concerns, but take the opposite view - i.e. +1 for the release.
>
> I think if we do not have a release now, we will be unable to release again
> for some time due to the immense amount of changes that we need to put in
> for the upcoming AMQP 0-10 spec, and for introducing clustering and other
> capabilities across the two brokers.
>
> For that reason I say we should attempt the following:
>
> Define a point in the very near future (5 days or less) when we cut the
> branch for M2.
>
> The minimum interoperability for me is that Java, .NET, C++ and Python can
> all talk through the released brokers (preferably both C++ and Java) to
> other clients using basic AMQP functionaliy.  I don't think other clients
> should need to support the extended field types, except in as much as we
> want those clients to be able to communicate to a Java client.  I think we
> already have the C# and C++ clients in the necessary state for that - or if
> not, then very close.
>
> I'm also happy to release the Python and Ruby (if the latter is anything
> like ready) but including a notice as to the interoperability limitations -
> in particular you cannot send certain types of data from the JMS
> implementation to these clients (as it requires the extended field table).
>
> Your concern that
>
> "The main development work should occur on trunk. Otherwise we will end
> up splitting our community into those working on M2-Interop-fixes and
> those working on 0.9."
>
> Is actually what has brought us to this point.  Currently a large number of
> developers (possibly a majority) are working on 0-9 branch, while the rest
> of us are working on trunk.  We need to sunch these up, and concentrate our
> efforts.
>
> -- Rob
>
>
> On 07/03/07, Martin Ritchie <ritchiem@apache.org> wrote:
> >
> > From Marnie
> > > We have quite a bit of work to consider/do prior to release including
> > > interop testing, docs etc. Happy to raise JIRAs (or assist the release
> > > manager) for an M2 set of tasks if we proceed.
> >
> > From Alan
> > > ll be merging the 0-9 C++ branch (Jira QPID-400) soon, speak up if you
> > > ow of any outstanding issues. The plan is to merge python first for
> > > the tests (branch python speaks both old & new protocols) then the C++
> > > codebase.
> >
> > I'm concerned about the timing of these events. If we are to perform
> > an M2 release whose focus is Interop between the various components
> > then we should be specify which components and ensuring they interop.
> > BEFORE we branch and therefore before we merge any 0.9 work to trunk.
> > The main development work should occur on trunk. Otherwise we will end
> > up splitting our community into those working on M2-Interop-fixes and
> > those working on 0.9.
> >
> > How are we supposed to merge changes that occur between the two
> > branches? I always thought that when we branched for a release only
> > the smallest bug fix changes should be merged (At the release managers
> > discretion) If the trunk isn't at the point to release then we
> > shouldn't branch.
> >
> > My current concerns that I'd like to address on the list are:
> >
> > - The scope of interop language requirements. Java->.Net is ok AFAIK
> > but what about C++,Python,Ruby. Esp. given the non-standard field
> > table in the java client.
> >
> > - Where development will occur.
> >
> > - How the 0.9 merge will effect this development process.
> >
> > I think the discussion the discussion around scoping for M2 needs more
> > work so that we all have a clear view of what needs to be done before
> > we can perform release.
> >
> > Until these things have been cleared up I feel as though I should -1 the
> > release
> >
> > [ -1 ] M2 Release inc Java, C++, .NET
> > [ -1 ] Python and Ruby clients
> >
> > --
> > Martin Ritchie
> >
>

Mime
View raw message