Qpid M2 Branching / C++ 0.9 Merging

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

>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

Re: Qpid M2 Branching / C++ 0.9 Merging

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

On 07/03/07, Robert Godfrey <ro...@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 <ru...@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 <ro...@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 <ri...@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

Re: Qpid M2 Branching / C++ 0.9 Merging

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

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 <ru...@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 <ro...@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 <ri...@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
> > >
> >
>

Re: Qpid M2 Branching / C++ 0.9 Merging

[Rupert Smith <ru...@googlemail.com>]

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 <ro...@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 <ri...@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
> >
>

Re: Qpid M2 Branching / C++ 0.9 Merging

[Gordon Sim <gs...@redhat.com>]

Robert Godfrey wrote:
> Since the Fieldtable implementation is likely to change radically in 0-10 I
> don't think we should put in any further work to us the original "extended"
> FieldTable.  Having said that it may be that for specific business purposes
> some of us will have a need to do that before our next release.  In which
> case we can make a patch against M2.

Ok. I'm happy to add in any types to M2 that are explicitly requested.

Re: Qpid M2 Branching / C++ 0.9 Merging

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

On 07/03/07, Gordon Sim <gs...@redhat.com> wrote:
>
> Robert Godfrey wrote:
> > Having said that, because of requirements put forward by people actually
> > using the software, we have built a higher level of interoperability at
> the
> > JMS level into the .net and C++ clients, and C++ broker (i.e. extending
> the
> > FieldTable to cope with the new types).
>
> The c++ trunk only (as far as I know) includes an update to cope with
> the 'binary' field table value type. It doesn't (as far as I know) cope
> with any of the other extended types.
>

Which is fine...  I think that for basic interoperability we no longer even
need this (I changed the Java so it sends a single integer number rather
than a binary).

Since the Fieldtable implementation is likely to change radically in 0-10 I
don't think we should put in any further work to us the original "extended"
FieldTable.  Having said that it may be that for specific business purposes
some of us will have a need to do that before our next release.  In which
case we can make a patch against M2.

-- Rob

Re: Qpid M2 Branching / C++ 0.9 Merging

[Gordon Sim <gs...@redhat.com>]

Robert Godfrey wrote:
> Having said that, because of requirements put forward by people actually
> using the software, we have built a higher level of interoperability at the
> JMS level into the .net and C++ clients, and C++ broker (i.e. extending the
> FieldTable to cope with the new types).

The c++ trunk only (as far as I know) includes an update to cope with 
the 'binary' field table value type. It doesn't (as far as I know) cope 
with any of the other extended types.

Re: Qpid M2 Branching / C++ 0.9 Merging

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

On 07/03/07, Robert Godfrey <ro...@gmail.com> wrote:
> On 07/03/07, Rupert Smith <ru...@googlemail.com> wrote:
> >
> > In which case, 5 days sounds adequate to me. (not including the weekend!).
> >
> > Rupert
>
>
> We'll let people have this weekend off... but let's not make a habit of it
> :-)
>
> -- Rob

When Apple send me their 8-core box then I'll be happy to do some
extra work at the weekend.


-- 
Martin Ritchie

Re: Qpid M2 Branching / C++ 0.9 Merging

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

On 07/03/07, Rupert Smith <ru...@googlemail.com> wrote:
>
> In which case, 5 days sounds adequate to me. (not including the weekend!).
>
> Rupert


We'll let people have this weekend off... but let's not make a habit of it
:-)

-- Rob

Re: Qpid M2 Branching / C++ 0.9 Merging

[Rupert Smith <ru...@googlemail.com>]

In which case, 5 days sounds adequate to me. (not including the weekend!).

Rupert

On 3/7/07, Robert Godfrey <ro...@gmail.com> wrote:
> My ambition for the M2 release is only to have interop at the basic AMQP
> level - that means that we will not be interoperable at the JMS level as
> this requires extensions on top of basic AMQP.  While we work those
> extensions through the AMQP process I don't think we need all the other
> clients to be operating to this level.  It is already clear that as we talk
> through these extensions to AMQP, other AMQP members are coming up with
> refinements to our initial solutions which mean we will have to rework.
> Having said that, because of requirements put forward by people actually
> using the software, we have built a higher level of interoperability at the
> JMS level into the .net and C++ clients, and C++ broker (i.e. extending the
> FieldTable to cope with the new types).
>
> On 07/03/07, Martin Ritchie <ri...@apache.org> wrote:
> >
> > This release is very important for the project as everyone has done so
> > much good work since M1 and it is precisely why we need to get a good
> > M2 release done before we have a quite period whilst we sort out our
> > position for 0-9 and 0-10. I am not against the release in any way I
> > think we need to do this release it is just important to scope it
> > correctly and ensure we manage it well as a divided community cannot
> > progress as fast as one that is fully behind the trunk.
>
>
>
> Yes - indeed.  I think that is everybody's feeling.  The idea of doing an M2
> release now is to recognise the great strides we have made since M1, and to
> put out a checkpoint of that which early adopters may use.  In the meantime
> that allows us to move trunk on, and make the necessary changes required to
> move us to AMQP 0-10 (and eventually) AMQP 1-0 support.
>
> It would be good to learn from the current difficulties that are being
> > faced with the maintaining two versions of our code base so that we
> > can all focus on driving Qpid forward as a whole.
> >
> > My understanding of the interop that we were after was more than just
> > being able to send simple messages between clients. If that is minimum
> > level we wish to support with this release then that is a much more
> > manageable task. Which is totally possible in the next few days which
> > won't hold up our 0.9 merge so we can push on to 0.10.
>
>
>  Excellent - this is what I think we are aiming at.  M2 will be a release of
> clients and brokers interoperable at an AMQP level.  In addition, the
> combination of Java client and Java Broker will be sufficiently JMS
> compliant to pass the JMS TCK.
>
> Do we want interop to go beyond sending simple messages between
> > clients to supporting something like the JMS Message types across all
> > clients?
>
>
>
> No - definitely not :-)
>
> The  mapping of JMS to AMQP has been proposed and is being worked on at the
> AMQP level, but it is premature to try to use our current encoding in all
> our clients until it is an AMQP standard.
>
> -- Rob
>

Re: Qpid M2 Branching / C++ 0.9 Merging

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

My ambition for the M2 release is only to have interop at the basic AMQP
level - that means that we will not be interoperable at the JMS level as
this requires extensions on top of basic AMQP.  While we work those
extensions through the AMQP process I don't think we need all the other
clients to be operating to this level.  It is already clear that as we talk
through these extensions to AMQP, other AMQP members are coming up with
refinements to our initial solutions which mean we will have to rework.
Having said that, because of requirements put forward by people actually
using the software, we have built a higher level of interoperability at the
JMS level into the .net and C++ clients, and C++ broker (i.e. extending the
FieldTable to cope with the new types).

On 07/03/07, Martin Ritchie <ri...@apache.org> wrote:
>
> This release is very important for the project as everyone has done so
> much good work since M1 and it is precisely why we need to get a good
> M2 release done before we have a quite period whilst we sort out our
> position for 0-9 and 0-10. I am not against the release in any way I
> think we need to do this release it is just important to scope it
> correctly and ensure we manage it well as a divided community cannot
> progress as fast as one that is fully behind the trunk.



Yes - indeed.  I think that is everybody's feeling.  The idea of doing an M2
release now is to recognise the great strides we have made since M1, and to
put out a checkpoint of that which early adopters may use.  In the meantime
that allows us to move trunk on, and make the necessary changes required to
move us to AMQP 0-10 (and eventually) AMQP 1-0 support.

It would be good to learn from the current difficulties that are being
> faced with the maintaining two versions of our code base so that we
> can all focus on driving Qpid forward as a whole.
>
> My understanding of the interop that we were after was more than just
> being able to send simple messages between clients. If that is minimum
> level we wish to support with this release then that is a much more
> manageable task. Which is totally possible in the next few days which
> won't hold up our 0.9 merge so we can push on to 0.10.


 Excellent - this is what I think we are aiming at.  M2 will be a release of
clients and brokers interoperable at an AMQP level.  In addition, the
combination of Java client and Java Broker will be sufficiently JMS
compliant to pass the JMS TCK.

Do we want interop to go beyond sending simple messages between
> clients to supporting something like the JMS Message types across all
> clients?



No - definitely not :-)

The  mapping of JMS to AMQP has been proposed and is being worked on at the
AMQP level, but it is premature to try to use our current encoding in all
our clients until it is an AMQP standard.

-- Rob

Re: Qpid M2 Branching / C++ 0.9 Merging

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

This release is very important for the project as everyone has done so
much good work since M1 and it is precisely why we need to get a good
M2 release done before we have a quite period whilst we sort out our
position for 0-9 and 0-10. I am not against the release in any way I
think we need to do this release it is just important to scope it
correctly and ensure we manage it well as a divided community cannot
progress as fast as one that is fully behind the trunk.

It would be good to learn from the current difficulties that are being
faced with the maintaining two versions of our code base so that we
can all focus on driving Qpid forward as a whole.

My understanding of the interop that we were after was more than just
being able to send simple messages between clients. If that is minimum
level we wish to support with this release then that is a much more
manageable task. Which is totally possible in the next few days which
won't hold up our 0.9 merge so we can push on to 0.10.

Do we want interop to go beyond sending simple messages between
clients to supporting something like the JMS Message types across all
clients?


-- 
Martin


On 07/03/07, Robert Godfrey <ro...@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 <ri...@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
> >
>

Re: Qpid M2 Branching / C++ 0.9 Merging

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

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

Re: Qpid M2 Branching / C++ 0.9 Merging

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

Robert Greig wrote:
> On 07/03/07, Andrew Stitcher <as...@redhat.com> wrote:
>
>> In theory this seems correct - that is we shouldn't hold up the C++
>> reorg for the 0-9 merge. But the main reason we haven't done it yet is
>> that svn tracks renames (and moving stuff around) extremely poorly and,
>> this to my understanding, could make the merge extremely painful if done
>> afterwards.

Here's the other way to do it: I backmerge C++ from trunk to 0-9 branch 
to pick up all useful work on the trunk, and we go ahead with cleanup on 
the branch. We do nothing on trunk except fixes for M2 - for C++ the 
trunk effectively becomes the M2 branch.

When an M2 branch is finally, M2 fix work will carry on the M2 branch. 
M2 fixes on trunk or M2 branch will be individually merged out to 0-9 if 
relevant, by hand if necessary due to file renames.

The 0-9 branch will be "merged" to trunk by simply replacing the trunk 
with the branch. Since any changes on the trunk to C++ will already be 
individually merged, there's no need for a painful merge at this point.

The only rename pain might be in merging M2 fixes, which will hopefully 
be minor.

>> Does anyone actually have experience with doing the wholesale renaming
>> and moving Alan is talking about on a svn branch.
It sucks. Even simple small-scale renaming with SVN sucks.
>> If not for this reasoning there is a lot of clean up work that we would
>> already have done on the branch.
Unless there's sudden agreement to create an M2 branch, I think the 
strategy outlined above will work with pretty much equivalent pain to 
branching immediately. Either way we can limit the pain to individual 
merges of small M2 fixes and make the major "merge" trivial.
>
> I think it is unfortunate that our scm tool is limiting us. I would
> fully support a move away from Subversion - a tool that has not IMHO
> lived up to the hype around it.
>
> RG
No kidding. Jim Meyering has experience with git and recommends it as a 
good alternative, he can give more details if there's support for such a 
move.

Cheers,
Alan.

Re: Qpid M2 Branching / C++ 0.9 Merging

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

On 07/03/07, Andrew Stitcher <as...@redhat.com> wrote:

> In theory this seems correct - that is we shouldn't hold up the C++
> reorg for the 0-9 merge. But the main reason we haven't done it yet is
> that svn tracks renames (and moving stuff around) extremely poorly and,
> this to my understanding, could make the merge extremely painful if done
> afterwards.

Yes I agree that Subversion has many key limitations in this area.

> Does anyone actually have experience with doing the wholesale renaming
> and moving Alan is talking about on a svn branch.

I found when doing the persistence work that the merges were very
painful. I only managed it without breaking things badly because I was
very involved with both trunk and the persistence branch.

I couldn't actually use any of the svn merge tools for the merge
because of the moves and renames so I ended up doing most of it
manually. winmerge is very useful!

> If not for this reasoning there is a lot of clean up work that we would
> already have done on the branch.

I think it is unfortunate that our scm tool is limiting us. I would
fully support a move away from Subversion - a tool that has not IMHO
lived up to the hype around it.

RG

Re: Qpid M2 Branching / C++ 0.9 Merging

[Andrew Stitcher <as...@redhat.com>]

On Wed, 2007-03-07 at 12:00 -0500, Alan Conway wrote:
> Robert Godfrey wrote:
> > I don't think any work should be getting held up... We have two parrallel
> > streams, the fact that currently one is "trunk" and the other is 
> > "0-9", and
> > we want to move to the situation where one is "M2" and the other is 
> > "trunk"
> > doesn't fundamentally change the dynamics of the problem (we could 
> > have two
> > streams called apple and banana and the problems would be the same - 
> > and it
> > would probably be less contentious :-) ).
> You're right. I can do the C++ reorg on the C++ 0-9 branch instead and 
> stop worrying people about a branch called "M2".

In theory this seems correct - that is we shouldn't hold up the C++
reorg for the 0-9 merge. But the main reason we haven't done it yet is
that svn tracks renames (and moving stuff around) extremely poorly and,
this to my understanding, could make the merge extremely painful if done
afterwards.

Does anyone actually have experience with doing the wholesale renaming
and moving Alan is talking about on a svn branch.

If not for this reasoning there is a lot of clean up work that we would
already have done on the branch.

Andrew

Re: Qpid M2 Branching / C++ 0.9 Merging

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

Robert Godfrey wrote:
> I don't think any work should be getting held up... We have two parrallel
> streams, the fact that currently one is "trunk" and the other is 
> "0-9", and
> we want to move to the situation where one is "M2" and the other is 
> "trunk"
> doesn't fundamentally change the dynamics of the problem (we could 
> have two
> streams called apple and banana and the problems would be the same - 
> and it
> would probably be less contentious :-) ).
You're right. I can do the C++ reorg on the C++ 0-9 branch instead and 
stop worrying people about a branch called "M2".

Cheers,
Alan.

Re: Qpid M2 Branching / C++ 0.9 Merging

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

I think I'd prefer us to say that we'll hold off the merge until next week
so that we can actually get approval for an M2 branch.

I don't think any work should be getting held up... We have two parrallel
streams, the fact that currently one is "trunk" and the other is "0-9", and
we want to move to the situation where one is "M2" and the other is "trunk"
doesn't fundamentally change the dynamics of the problem (we could have two
streams called apple and banana and the problems would be the same - and it
would probably be less contentious :-) ).

As I understand it right now, most to all work on the Java side is being
done on "trunk", most to all work on the C++ side is being done on "0-9".
Therefore whenever we time the branching/merging there shouldn't be a lot of
conflicts.  What we want to avoid is merging / branching while people still
have a significant amount of work checked out.  We should allow people a few
days grace to complete the work they are currently undertaking, and then a
few more days to test it :-)

But as of now, other than bug-fixes, I don't think we should be doing any
new work on trunk.

Thoughts?
Rob

On 07/03/07, Alan Conway <ac...@redhat.com> wrote:
>
> Martin Ritchie 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.
> Simple solution to this: we make the M2 branch now.  The trunk is the
> place for forward development, if a pending release is holding back
> forward development that is the sign that we need a release branch. That
> will allow all the 0-9 work to come back to the trunk with no risk to
> M2. Work that should be on both will have to be merged across, there's
> no way around that but it doesn't make sense to hold up trunk
> development for M2 anymore.
>
> Cheers,
> Alan.
>

Re: Qpid M2 Branching / C++ 0.9 Merging

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

On 07/03/07, Alan Conway <ac...@redhat.com> wrote:
> Robert Godfrey wrote:
> > OK - so can we set a date for the creation of the M2 branch, and the
> > merging
> > of the 0-9 branch down to trunk?
> We don't have to merge the entire branch in one shot, indeed I think
> that would be very unwise. I strongly suggest that merging each
> sub-project should be a separate effort. Making the branch must preceed
> the merge efforts but it doesn't have to coincide with them.
> > Would early next week (Monday or Tuesday) be OK with everybody for
> > instance?
> I can wait till Monday, but I don't want to wait longer than that.
>
> > In the meantime we won't do anything new to trunk other than check in
> > things
> > we are working on, or fix bugs?
> I would like to merge 0-9 python, it's fully compatible and it's one
> less piece to worry about.
> > Thoughts?
> I see no reason to delay making the branch. It enables forward movement
> of projects that are ready to move, and it doesn't impose anything on
> projects that are not.
>
> Cheers,
> Alan.

The only difference with creating the M2 branch now and M1 is that
when we made M1 the code was done. Here we are saying we want to do M2
based on this code.

We can obviously take a branch from any revision point in the SVN
history so whiter we do it now or later doesn't really make much
difference. It would be good to get general agreement via the vote
that performing a release is something that we want to do. I don't
think there will be any real objections to working for a release after
all releasing code is a good thing.


-- 
Martin Ritchie

Re: Qpid M2 Branching / C++ 0.9 Merging

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

Robert Godfrey wrote:
> OK - so can we set a date for the creation of the M2 branch, and the 
> merging
> of the 0-9 branch down to trunk?
We don't have to merge the entire branch in one shot, indeed I think 
that would be very unwise. I strongly suggest that merging each 
sub-project should be a separate effort. Making the branch must preceed 
the merge efforts but it doesn't have to coincide with them.
> Would early next week (Monday or Tuesday) be OK with everybody for 
> instance?
I can wait till Monday, but I don't want to wait longer than that.

> In the meantime we won't do anything new to trunk other than check in 
> things
> we are working on, or fix bugs?
I would like to merge 0-9 python, it's fully compatible and it's one 
less piece to worry about.
> Thoughts?
I see no reason to delay making the branch. It enables forward movement 
of projects that are ready to move, and it doesn't impose anything on 
projects that are not.

Cheers,
Alan.

Re: Qpid M2 Branching / C++ 0.9 Merging

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

OK - so can we set a date for the creation of the M2 branch, and the merging
of the 0-9 branch down to trunk?

Would early next week (Monday or Tuesday) be OK with everybody for instance?

In the meantime we won't do anything new to trunk other than check in things
we are working on, or fix bugs?

Thoughts?

Rob

On 07/03/07, Martin Ritchie <ri...@apache.org> wrote:
>
> On 07/03/07, Alan Conway <ac...@redhat.com> wrote:
> > Martin Ritchie 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.
> > Simple solution to this: we make the M2 branch now.  The trunk is the
> > place for forward development, if a pending release is holding back
> > forward development that is the sign that we need a release branch. That
> > will allow all the 0-9 work to come back to the trunk with no risk to
> > M2. Work that should be on both will have to be merged across, there's
> > no way around that but it doesn't make sense to hold up trunk
> > development for M2 anymore.
>
> The suggestion wasn't to hold up development for M2 but rather to hold
> up M2 release until development has ticked all the boxes we have set
> ourselves for M2 release. I understand the desire to get 0.9 on the
> trunk and think that should be our main driver just now but we do need
> to do a release and that release needs to contain a very stable
> release as we will not be doing another release for sometime, if
> previous discussions are anything to go by.
>
> > Cheers,
> > Alan.
> >
>
>
> --
> Martin Ritchie
>

Re: Qpid M2 Branching / C++ 0.9 Merging

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

The java broker doesn't correctly count the message references so
occasionally we are seeing errors in the tests. I also have to commit
my topic matching exchange which seems stuck at 90% done.


On 07/03/07, Robert Godfrey <ro...@gmail.com> wrote:
> Can anyone who has oustanding work on the trunk pipe up now...  I am working
> on a refactoring for post the M2 cut to support multiple versions of the
> protocol in the Java Broker, so personally I'm in favour of an early M2
> cut...  however I still have concerns about making an M2 branch before we've
> actually concluded the vote on an M2 release :-)
>
> -- Rob
>
> On 07/03/07, Alan Conway <ac...@redhat.com> wrote:
> >
> > Martin Ritchie wrote:
> > > The suggestion wasn't to hold up development for M2 but rather to hold
> > > up M2 release until development has ticked all the boxes we have set
> > > ourselves for M2 release. I understand the desire to get 0.9 on the
> > > trunk and think that should be our main driver just now but we do need
> > > to do a release and that release needs to contain a very stable
> > > release as we will not be doing another release for sometime, if
> > > previous discussions are anything to go by.
> > >
> > It sounds like we're in agreement that we should start the M2 branch
> > soon so 0.9 work can proceed. I'd like to create the branch early to
> > merge C++ - that doesn't prevent Java from holding off on the 0-9 merge
> > to finish up stuff aimed at both M2 and trunk before diverging the two
> > with the 0-9 merge.
> >
> > Cheers,
> > Alan.
> >
>


-- 
Martin Ritchie

Re: Qpid M2 Branching / C++ 0.9 Merging

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

Can anyone who has oustanding work on the trunk pipe up now...  I am working
on a refactoring for post the M2 cut to support multiple versions of the
protocol in the Java Broker, so personally I'm in favour of an early M2
cut...  however I still have concerns about making an M2 branch before we've
actually concluded the vote on an M2 release :-)

-- Rob

On 07/03/07, Alan Conway <ac...@redhat.com> wrote:
>
> Martin Ritchie wrote:
> > The suggestion wasn't to hold up development for M2 but rather to hold
> > up M2 release until development has ticked all the boxes we have set
> > ourselves for M2 release. I understand the desire to get 0.9 on the
> > trunk and think that should be our main driver just now but we do need
> > to do a release and that release needs to contain a very stable
> > release as we will not be doing another release for sometime, if
> > previous discussions are anything to go by.
> >
> It sounds like we're in agreement that we should start the M2 branch
> soon so 0.9 work can proceed. I'd like to create the branch early to
> merge C++ - that doesn't prevent Java from holding off on the 0-9 merge
> to finish up stuff aimed at both M2 and trunk before diverging the two
> with the 0-9 merge.
>
> Cheers,
> Alan.
>

Re: Qpid M2 Branching / C++ 0.9 Merging

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

Martin Ritchie wrote:
> The suggestion wasn't to hold up development for M2 but rather to hold
> up M2 release until development has ticked all the boxes we have set
> ourselves for M2 release. I understand the desire to get 0.9 on the
> trunk and think that should be our main driver just now but we do need
> to do a release and that release needs to contain a very stable
> release as we will not be doing another release for sometime, if
> previous discussions are anything to go by.
>
It sounds like we're in agreement that we should start the M2 branch 
soon so 0.9 work can proceed. I'd like to create the branch early to 
merge C++ - that doesn't prevent Java from holding off on the 0-9 merge 
to finish up stuff aimed at both M2 and trunk before diverging the two 
with the 0-9 merge.

Cheers,
Alan.

Re: Qpid M2 Branching / C++ 0.9 Merging

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

On 07/03/07, Alan Conway <ac...@redhat.com> wrote:
> Martin Ritchie 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.
> Simple solution to this: we make the M2 branch now.  The trunk is the
> place for forward development, if a pending release is holding back
> forward development that is the sign that we need a release branch. That
> will allow all the 0-9 work to come back to the trunk with no risk to
> M2. Work that should be on both will have to be merged across, there's
> no way around that but it doesn't make sense to hold up trunk
> development for M2 anymore.

The suggestion wasn't to hold up development for M2 but rather to hold
up M2 release until development has ticked all the boxes we have set
ourselves for M2 release. I understand the desire to get 0.9 on the
trunk and think that should be our main driver just now but we do need
to do a release and that release needs to contain a very stable
release as we will not be doing another release for sometime, if
previous discussions are anything to go by.

> Cheers,
> Alan.
>


-- 
Martin Ritchie

Re: Qpid M2 Branching / C++ 0.9 Merging

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

Martin Ritchie 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. 
Simple solution to this: we make the M2 branch now.  The trunk is the 
place for forward development, if a pending release is holding back 
forward development that is the sign that we need a release branch. That 
will allow all the 0-9 work to come back to the trunk with no risk to 
M2. Work that should be on both will have to be merged across, there's 
no way around that but it doesn't make sense to hold up trunk 
development for M2 anymore.

Cheers,
Alan.