qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Godfrey" <rob.j.godf...@gmail.com>
Subject Re: Qpid M2 Branching / C++ 0.9 Merging
Date Wed, 07 Mar 2007 15:35:47 GMT
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

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
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message