qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Ritchie" <ritch...@apache.org>
Subject Re: Qpid M2 Branching / C++ 0.9 Merging
Date Wed, 07 Mar 2007 15:47:56 GMT
On 07/03/07, Robert Godfrey <rob.j.godfrey@gmail.com> wrote:
> We need to at least aim to timebox it.  I think we need a few days before we
> count the votes :-) and then we can set ourselves a limit for how long we
> have to get the code in shape for an M2 release.  In this we should
> concentrate our efforts on the most popular clients (i.e. if Ruby doesn't
> make the cut because no-one has time to test it, then I, personally, don't
> have an issue).
>
> Bear in mind that however we split it there are two parallel streams of
> working going on right now, and we do have merging issues.  It's just the
> people working on trunk aren't seeing them :-).
>
> The idea is to try to bring the 0-8 stuff to a good point and release, and
> then get everyone working on trunk again, as much as possible.
>
> -- Rob

A big +1 for that.

I guess my problem with the vote was it seemed like we were voting to
release the clients rather than voting to start thinking about
defining a time frame. I think we should include as many clients as
possible so we should set a date and as you say the clients that don't
make the cut don't make the release.

So I'm happy to make my vote a +1 for the release lets just get the
dates sorted out soon.

 [ +1 ] M2 Release

> On 07/03/07, Rupert Smith <rupertlssmith@googlemail.com> wrote:
> >
> > 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
> > > >
> > >
> >
>


-- 
Martin Ritchie

Mime
View raw message