M3 Freeze

[Aidan Skinner <ai...@apache.org>]

Qpideers,

Gentle reminder that barring catastrophe, freeze is on the 8th, and
then it's a couple of weeks of stabalisation.

I'll push an alpha on the weekend for the outside world to start
testing, a beta on the 14th and then tag RC1 on the 21st and start the
voting process here and on incubator-general simultaneously for a
release on the 29th.

Freeze: 8th
Beta: 14th
RC1: 21st
Release: 29th

- Aidan
-- 
Apache Qpid - World Domination through Advanced Message Queueing
http://cwiki.apache.org/qpid
"Nine-tenths of wisdom consists in being wise in time." - Theodore Roosevelt

Re: M3 Freeze

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

2008/8/5 Aidan Skinner <ai...@apache.org>:
> Qpideers,
>
> Gentle reminder that barring catastrophe, freeze is on the 8th, and
> then it's a couple of weeks of stabalisation.
>
> I'll push an alpha on the weekend for the outside world to start
> testing, a beta on the 14th and then tag RC1 on the 21st and start the
> voting process here and on incubator-general simultaneously for a
> release on the 29th.
>
> Freeze: 8th
> Beta: 14th
> RC1: 21st
> Release: 29th
>
> - Aidan
> --
> Apache Qpid - World Domination through Advanced Message Queueing
> http://cwiki.apache.org/qpid
> "Nine-tenths of wisdom consists in being wise in time." - Theodore Roosevelt

+1 Sounds good to me


-- 
Martin Ritchie

Re: M3 Freeze

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

2008/8/5 Alan Conway <ac...@redhat.com>:
> On Tue, 2008-08-05 at 13:50 +0100, Aidan Skinner wrote:
>> On Tue, Aug 5, 2008 at 1:41 PM, Gordon Sim <gs...@redhat.com> wrote:
>>
>> > Can you remind me the process that was agreed around branching?
>>
>> What I recall us settling us on was "don't, not unless there's a
>> (customer money) gun to your head and it can't possibly wait until the
>> next release".
>
> What I recall us saying is "don't until you really need one". We need
> one if there is any post-M3 work going on during the freeze. I'm working
> on clustering code that is well decoupled but still poses a risk of me
> breaking the C++ broker. There may be others working on post-M3 work as
> well.
>
> I'd suggest we create an M3 branch and allow post-M3 work on trunk,
> merging M3 to trunk as we go. The alternative is to use trunk for M3 and
> create a post-M3-branch but that seems backwards to me.
>
> Cheers,
> Alan.

I think we should try and focus on keeping M3 on trunk if we branch
then the likely hood of stabilisation and bug fixing being done is
probably slim.

If there is work going on that is for post-M3 then the desire to get
on with that should help focus us on getting M3 out on time.

I know we all have work to do that is for post-M3 but if Apache Qpid
is going to actually release anything we need to work at it as well as
our new features.

Cheers

Martin

-- 
Martin Ritchie

Re: M3 Freeze

[Aidan Skinner <ai...@apache.org>]

On Tue, Aug 5, 2008 at 7:23 PM, Rajith Attapattu <ra...@gmail.com> wrote:

> The general practise (as seen in other apache projects and in general) is
> not to freeze the trunk.

I am familiar with many projects which do freeze the trunk.

> If need be these changes can be kept in a local copy btw the freeze and
> release, but having read Alans comments I agree with him that a branch is
> probably a better and safer option.

Will the Java changes impact the stability of the non-clustery bit of
the client? If not, they can go on trunk..

- Aidan
-- 
Apache Qpid - World Domination through Advanced Message Queueing
http://cwiki.apache.org/qpid
"Nine-tenths of wisdom consists in being wise in time." - Theodore Roosevelt

Re: M3 Freeze

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

The general practise (as seen in other apache projects and in general) is
not to freeze the trunk.
The java client will also have some clustering related changes to go along
with Alans stuff on C++.
If need be these changes can be kept in a local copy btw the freeze and
release, but having read Alans comments I agree with him that a branch is
probably a better and safer option.

Regards,

Rajith

On Tue, Aug 5, 2008 at 1:56 PM, Alan Conway <ac...@redhat.com> wrote:

> On Tue, 2008-08-05 at 15:06 +0100, Aidan Skinner wrote:
> > On Tue, Aug 5, 2008 at 2:41 PM, Alan Conway <ac...@redhat.com> wrote:
> >
> > > What I recall us saying is "don't until you really need one". We need
> > > one if there is any post-M3 work going on during the freeze. I'm
> working
> > > on clustering code that is well decoupled but still poses a risk of me
> > > breaking the C++ broker. There may be others working on post-M3 work as
> > > well.
> >
> > Is that something you need to land before M3 goes out? I guess ideally
> > you'd be doing this on a feature branch that tracks trunk, probably
> > easier with git than svn though. :/
>
> I'm doing small incremental merges. The new functionality does nothing
> unless explicitly enabled so it doesn't interfere with non-cluster use
> of the broker. I prefer incremental merges to trunk (or some shared
> post-M3 branch) so that my code gets continuously integrated with any
> other work that is going on.
>
> > > I'd suggest we create an M3 branch and allow post-M3 work on trunk,
> > > merging M3 to trunk as we go. The alternative is to use trunk for M3
> and
> > > create a post-M3-branch but that seems backwards to me.
> >
> > If you have to commit your stuff in the weeks between freeze and
> > release then yeah, that makes sense.
>
> The other advantage of an M3 branch over a frozen trunk is that it's
> unlikely anyone will accidentally commit post-M3 changes to an explicit
> M3 branch, which is always a risk with the trunk.
>
>
> Cheers,
> Alan.
>
>


-- 
Regards,

Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/

Re: M3 Freeze

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

On Wed, 2008-08-06 at 10:06 +0100, Aidan Skinner wrote:
> On Tue, Aug 5, 2008 at 6:56 PM, Alan Conway <ac...@redhat.com> wrote:
> 
> > I'm doing small incremental merges. The new functionality does nothing
> > unless explicitly enabled so it doesn't interfere with non-cluster use
> > of the broker. I prefer incremental merges to trunk (or some shared
> > post-M3 branch) so that my code gets continuously integrated with any
> > other work that is going on.
> 
> If it doesn't affect stablity, it isn't really affected by the freeze,
> you can quite happily keep doing this. :)

It *shouldn't* affect stability unless I goof (which does occasionally
happen :) so there's a risk doing this on the same branch as the
release.

As per earlier email I've accepted freezing the trunk for release and
creating an after_M3 branch for anything that's not part of M3 and poses
a risk on the trunk.

Cheers,
Alan.

Re: M3 Freeze

[Aidan Skinner <ai...@apache.org>]

On Tue, Aug 5, 2008 at 6:56 PM, Alan Conway <ac...@redhat.com> wrote:

> I'm doing small incremental merges. The new functionality does nothing
> unless explicitly enabled so it doesn't interfere with non-cluster use
> of the broker. I prefer incremental merges to trunk (or some shared
> post-M3 branch) so that my code gets continuously integrated with any
> other work that is going on.

If it doesn't affect stablity, it isn't really affected by the freeze,
you can quite happily keep doing this. :)

>> If you have to commit your stuff in the weeks between freeze and
>> release then yeah, that makes sense.
>
> The other advantage of an M3 branch over a frozen trunk is that it's
> unlikely anyone will accidentally commit post-M3 changes to an explicit
> M3 branch, which is always a risk with the trunk.

I'm not overly worried about this, it's easy enough to catch during
code review and revert it, in the unlikely (I hope) event that it
happens and much less work than trying to maintain branches.

- Aidan
-- 
Apache Qpid - World Domination through Advanced Message Queueing
http://cwiki.apache.org/qpid
"Nine-tenths of wisdom consists in being wise in time." - Theodore Roosevelt

Re: M3 Freeze

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

On Tue, 2008-08-05 at 15:06 +0100, Aidan Skinner wrote:
> On Tue, Aug 5, 2008 at 2:41 PM, Alan Conway <ac...@redhat.com> wrote:
> 
> > What I recall us saying is "don't until you really need one". We need
> > one if there is any post-M3 work going on during the freeze. I'm working
> > on clustering code that is well decoupled but still poses a risk of me
> > breaking the C++ broker. There may be others working on post-M3 work as
> > well.
> 
> Is that something you need to land before M3 goes out? I guess ideally
> you'd be doing this on a feature branch that tracks trunk, probably
> easier with git than svn though. :/

I'm doing small incremental merges. The new functionality does nothing
unless explicitly enabled so it doesn't interfere with non-cluster use
of the broker. I prefer incremental merges to trunk (or some shared
post-M3 branch) so that my code gets continuously integrated with any
other work that is going on. 

> > I'd suggest we create an M3 branch and allow post-M3 work on trunk,
> > merging M3 to trunk as we go. The alternative is to use trunk for M3 and
> > create a post-M3-branch but that seems backwards to me.
> 
> If you have to commit your stuff in the weeks between freeze and
> release then yeah, that makes sense.

The other advantage of an M3 branch over a frozen trunk is that it's
unlikely anyone will accidentally commit post-M3 changes to an explicit
M3 branch, which is always a risk with the trunk.


Cheers,
Alan.

Re: M3 Freeze

[Aidan Skinner <ai...@apache.org>]

On Tue, Aug 5, 2008 at 2:41 PM, Alan Conway <ac...@redhat.com> wrote:

> What I recall us saying is "don't until you really need one". We need
> one if there is any post-M3 work going on during the freeze. I'm working
> on clustering code that is well decoupled but still poses a risk of me
> breaking the C++ broker. There may be others working on post-M3 work as
> well.

Is that something you need to land before M3 goes out? I guess ideally
you'd be doing this on a feature branch that tracks trunk, probably
easier with git than svn though. :/

> I'd suggest we create an M3 branch and allow post-M3 work on trunk,
> merging M3 to trunk as we go. The alternative is to use trunk for M3 and
> create a post-M3-branch but that seems backwards to me.

If you have to commit your stuff in the weeks between freeze and
release then yeah, that makes sense.

- Aidan
-- 
Apache Qpid - World Domination through Advanced Message Queueing
http://cwiki.apache.org/qpid
"Nine-tenths of wisdom consists in being wise in time." - Theodore Roosevelt

Re: M3 Freeze

[Aidan Skinner <ai...@apache.org>]

On Fri, Aug 8, 2008 at 6:11 PM, Gordon Sim <gs...@redhat.com> wrote:

> I don't think a general after_M3 branch is conducive to encouraging the
> community to focus on getting a good release together.

If it's something we absoloutely *have* to have I can live with it,
but I'd rather not have it and I haven't created it. I also can't see
myself having the time to merge things from it to trunk post-release.
If I have spare cycles updating the forrest site seems like a better
use of them to me.

- Aidan
-- 
Apache Qpid - World Domination through Advanced Message Queueing
http://cwiki.apache.org/qpid
"Nine-tenths of wisdom consists in being wise in time." - Theodore Roosevelt

Re: M3 Freeze

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

Alan Conway wrote:
> OK, you've convinced me this might work out better. I suggest a single
> after_M3 branch for anyone doing post-M3 work so we don't have multiple
> independent feature branches to integrate after the freeze. After the
> freeze we can merge after_M3 back to trunk and delete the branch.
> 
> Aidan can you create an after_M3 branch from the point we declare the
> trunk frozen?

I think the responsibility for creating a feature branch and merging it 
back should lie with the feature developer(s) themselves.

I don't think a general after_M3 branch is conducive to encouraging the 
community to focus on getting a good release together.

Re: M3 Freeze

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

On Tue, 2008-08-05 at 21:41 -0400, Rafael Schloming wrote:
> Alan Conway wrote:
> > On Tue, 2008-08-05 at 13:50 +0100, Aidan Skinner wrote:
> >> On Tue, Aug 5, 2008 at 1:41 PM, Gordon Sim <gs...@redhat.com> wrote:
> >>
> >>> Can you remind me the process that was agreed around branching?
> >> What I recall us settling us on was "don't, not unless there's a
> >> (customer money) gun to your head and it can't possibly wait until the
> >> next release".
> > 
> > What I recall us saying is "don't until you really need one". We need
> > one if there is any post-M3 work going on during the freeze. I'm working
> > on clustering code that is well decoupled but still poses a risk of me
> > breaking the C++ broker. There may be others working on post-M3 work as
> > well.
> > 
> > I'd suggest we create an M3 branch and allow post-M3 work on trunk,
> > merging M3 to trunk as we go. The alternative is to use trunk for M3 and
> > create a post-M3-branch but that seems backwards to me. 
> 
> I thought what we said was that in general during a project-wide 
> release, most everyone should be focused stabilizing trunk, and that if 
> someone really really needs to do new feature development during that 
> period, they should create a feature branch.

OK, you've convinced me this might work out better. I suggest a single
after_M3 branch for anyone doing post-M3 work so we don't have multiple
independent feature branches to integrate after the freeze. After the
freeze we can merge after_M3 back to trunk and delete the branch.

Aidan can you create an after_M3 branch from the point we declare the
trunk frozen?

Cheers,
Alan

Re: M3 Freeze

[Rafael Schloming <ra...@redhat.com>]

Alan Conway wrote:
> On Tue, 2008-08-05 at 13:50 +0100, Aidan Skinner wrote:
>> On Tue, Aug 5, 2008 at 1:41 PM, Gordon Sim <gs...@redhat.com> wrote:
>>
>>> Can you remind me the process that was agreed around branching?
>> What I recall us settling us on was "don't, not unless there's a
>> (customer money) gun to your head and it can't possibly wait until the
>> next release".
> 
> What I recall us saying is "don't until you really need one". We need
> one if there is any post-M3 work going on during the freeze. I'm working
> on clustering code that is well decoupled but still poses a risk of me
> breaking the C++ broker. There may be others working on post-M3 work as
> well.
> 
> I'd suggest we create an M3 branch and allow post-M3 work on trunk,
> merging M3 to trunk as we go. The alternative is to use trunk for M3 and
> create a post-M3-branch but that seems backwards to me. 

I thought what we said was that in general during a project-wide 
release, most everyone should be focused stabilizing trunk, and that if 
someone really really needs to do new feature development during that 
period, they should create a feature branch.

Doing feature development during a release creates more work for 
everyone, so I tend to think a policy that discourages it, or at least 
puts the merge burden onto those doing the new feature development is 
quite sensible.

Ultimately the choice of how to branch comes down to who is doing the 
merging. If we branch for M3 prior to stabilizing, we either need a 
double commit policy (every commit needs to be both to the M3 branch and 
trunk) or we need to do a wholesale merge once the release is done. The 
latter option completely defeats your goal of integrating early and 
often, and the former option is a huge burden considering that it takes 
easily an hour to rigorously run through all the various java test 
profiles prior to committing to just one branch.

If you flip things around and take a feature branch then its essentially 
you (and probably me) doing merges from trunk whenever we feel the urge 
to integrate, and we will be in a much better position to resolve any 
merge conflicts since we'll be familiar with both the old code and the 
new code.

So as someone who's likely to be participating on both sides of this, I 
tend to think creating a feature branch is going to be much less work 
all around.

--Rafael

Re: M3 Freeze

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

On Tue, 2008-08-05 at 13:50 +0100, Aidan Skinner wrote:
> On Tue, Aug 5, 2008 at 1:41 PM, Gordon Sim <gs...@redhat.com> wrote:
> 
> > Can you remind me the process that was agreed around branching?
> 
> What I recall us settling us on was "don't, not unless there's a
> (customer money) gun to your head and it can't possibly wait until the
> next release".

What I recall us saying is "don't until you really need one". We need
one if there is any post-M3 work going on during the freeze. I'm working
on clustering code that is well decoupled but still poses a risk of me
breaking the C++ broker. There may be others working on post-M3 work as
well.

I'd suggest we create an M3 branch and allow post-M3 work on trunk,
merging M3 to trunk as we go. The alternative is to use trunk for M3 and
create a post-M3-branch but that seems backwards to me. 

Cheers,
Alan.

Re: M3 Freeze

[Aidan Skinner <ai...@apache.org>]

On Tue, Aug 5, 2008 at 1:41 PM, Gordon Sim <gs...@redhat.com> wrote:

> Can you remind me the process that was agreed around branching?

What I recall us settling us on was "don't, not unless there's a
(customer money) gun to your head and it can't possibly wait until the
next release".

I'm intending on creating an RC tag and moving that along trunk if
more than 1 RC is necessary, but not a branch.

- Aidan
-- 
Apache Qpid - World Domination through Advanced Message Queueing
http://cwiki.apache.org/qpid
"Nine-tenths of wisdom consists in being wise in time." - Theodore Roosevelt

Re: M3 Freeze

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

Aidan Skinner wrote:
> Qpideers,
> 
> Gentle reminder that barring catastrophe, freeze is on the 8th, and
> then it's a couple of weeks of stabalisation.
> 
> I'll push an alpha on the weekend for the outside world to start
> testing, a beta on the 14th and then tag RC1 on the 21st and start the
> voting process here and on incubator-general simultaneously for a
> release on the 29th.
> 
> Freeze: 8th
> Beta: 14th
> RC1: 21st
> Release: 29th
> 
> - Aidan

Can you remind me the process that was agreed around branching?

Re: M3 Freeze

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

Aidan Skinner wrote:
> On Thu, Aug 7, 2008 at 3:40 PM, Andrew Stitcher <as...@redhat.com> wrote:
> 
>> On Thu, 2008-08-07 at 15:32 +0100, Martin Ritchie wrote:
> 
>>> 2008/8/7 Aidan Skinner <ai...@apache.org>:
> 
>>>> I'm okay with this going in if guys you are. :)
>>>>
>>> Are you suggesting holding the freeze till Monday as 'Last thing
>>> Friday' == 'First thing Monday'?
>> I actually meant 3 working days so last thing Weds, but I definitely
>> don't want to wait longer than that, if it's not ready by then, we just
>> freeze anyway. But if you want to suggest sooner we can discuss.
> 
> I'm suggesting a freeze exception for this and only[1] this, and
> otherwise moving trunk into stabalisation mode as planned. I realise
> I'm basically making up policy as I go along here though. :)

+1 (sorry, sent a mail suggesting the same thing before I saw this!)

Re: M3 Freeze

[Aidan Skinner <ai...@apache.org>]

On Thu, Aug 7, 2008 at 3:40 PM, Andrew Stitcher <as...@redhat.com> wrote:

> On Thu, 2008-08-07 at 15:32 +0100, Martin Ritchie wrote:

>> 2008/8/7 Aidan Skinner <ai...@apache.org>:

>> > I'm okay with this going in if guys you are. :)
>> >
>> Are you suggesting holding the freeze till Monday as 'Last thing
>> Friday' == 'First thing Monday'?
>
> I actually meant 3 working days so last thing Weds, but I definitely
> don't want to wait longer than that, if it's not ready by then, we just
> freeze anyway. But if you want to suggest sooner we can discuss.

I'm suggesting a freeze exception for this and only[1] this, and
otherwise moving trunk into stabalisation mode as planned. I realise
I'm basically making up policy as I go along here though. :)

- Aidan

[1] If anybody else needs/wants one, now would be a good time to discuss it. ;)
-- 
Apache Qpid - World Domination through Advanced Message Queueing
http://cwiki.apache.org/qpid
"Nine-tenths of wisdom consists in being wise in time." - Theodore Roosevelt

Re: M3 Freeze

[Aidan Skinner <ai...@apache.org>]

On Thu, Aug 7, 2008 at 4:27 PM, Steve Huston <sh...@riverace.com> wrote:

>> From: Gordon Sim [mailto:gsim@redhat.com]

>> So I'd suggest not having a general delay in the freeze, but
> allowing
>> windows port patches to be submitted and applied by wed next week.
>> Steve, would that work for you?
>
> Yes, that would be great! Thank you for the support.

Thanks for doing the work! :D

- Aidan
-- 
Apache Qpid - World Domination through Advanced Message Queueing
http://cwiki.apache.org/qpid
"Nine-tenths of wisdom consists in being wise in time." - Theodore Roosevelt

RE: M3 Freeze

[Steve Huston <sh...@riverace.com>]

> -----Original Message-----
> From: Gordon Sim [mailto:gsim@redhat.com] 
> Sent: Thursday, August 07, 2008 11:13 AM
> To: qpid-dev@incubator.apache.org
> Subject: Re: M3 Freeze
> 
> 
> Andrew Stitcher wrote:
> > On Thu, 2008-08-07 at 15:32 +0100, Martin Ritchie wrote:
> >> 2008/8/7 Aidan Skinner <ai...@apache.org>:
> >>> On Thu, Aug 7, 2008 at 11:31 AM, Andrew Stitcher 
> <as...@redhat.com> wrote:
> >>>
> >>>> I do think however that it would be worth holding M3 for 
> a few days (say
> >>>> no more than 3) if it takes Steve a little longer than 
> that. I know this
> >>>> could be regarded as the thin end of the wedge, but this 
> the first
> >>>> significant platform port of the C++ broker and things 
> were bound to
> >>>> show up. However IMO it would be a significant extra for 
> M3 so worth
> >>>> waiting just a short while for.
> >>> I'm okay with this going in if guys you are. :)
> >>>
> >> Are you suggesting holding the freeze till Monday as 'Last thing
> >> Friday' == 'First thing Monday'?
> > 
> > I actually meant 3 working days so last thing Weds, but I
definitely
> > don't want to wait longer than that, if it's not ready by 
> then, we just
> > freeze anyway. But if you want to suggest sooner we can discuss.
> 
> I think it would be good to make an exception specifically 
> for Steve's 
> windows port and allow a few more days for that (e.g. up to Wed). It

> will be really nice to get that in for M3 and its already 
> very nearly there.
> 
> So I'd suggest not having a general delay in the freeze, but
allowing 
> windows port patches to be submitted and applied by wed next week. 
> Steve, would that work for you?

Yes, that would be great! Thank you for the support.

-Steve

Re: M3 Freeze

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

Andrew Stitcher wrote:
> On Thu, 2008-08-07 at 15:32 +0100, Martin Ritchie wrote:
>> 2008/8/7 Aidan Skinner <ai...@apache.org>:
>>> On Thu, Aug 7, 2008 at 11:31 AM, Andrew Stitcher <as...@redhat.com> wrote:
>>>
>>>> I do think however that it would be worth holding M3 for a few days (say
>>>> no more than 3) if it takes Steve a little longer than that. I know this
>>>> could be regarded as the thin end of the wedge, but this the first
>>>> significant platform port of the C++ broker and things were bound to
>>>> show up. However IMO it would be a significant extra for M3 so worth
>>>> waiting just a short while for.
>>> I'm okay with this going in if guys you are. :)
>>>
>> Are you suggesting holding the freeze till Monday as 'Last thing
>> Friday' == 'First thing Monday'?
> 
> I actually meant 3 working days so last thing Weds, but I definitely
> don't want to wait longer than that, if it's not ready by then, we just
> freeze anyway. But if you want to suggest sooner we can discuss.

I think it would be good to make an exception specifically for Steve's 
windows port and allow a few more days for that (e.g. up to Wed). It 
will be really nice to get that in for M3 and its already very nearly there.

So I'd suggest not having a general delay in the freeze, but allowing 
windows port patches to be submitted and applied by wed next week. 
Steve, would that work for you?

Re: M3 Freeze

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

On Thu, 2008-08-07 at 15:32 +0100, Martin Ritchie wrote:
> 2008/8/7 Aidan Skinner <ai...@apache.org>:
> > On Thu, Aug 7, 2008 at 11:31 AM, Andrew Stitcher <as...@redhat.com> wrote:
> >
> >> I do think however that it would be worth holding M3 for a few days (say
> >> no more than 3) if it takes Steve a little longer than that. I know this
> >> could be regarded as the thin end of the wedge, but this the first
> >> significant platform port of the C++ broker and things were bound to
> >> show up. However IMO it would be a significant extra for M3 so worth
> >> waiting just a short while for.
> >
> > I'm okay with this going in if guys you are. :)
> >
> Are you suggesting holding the freeze till Monday as 'Last thing
> Friday' == 'First thing Monday'?

I actually meant 3 working days so last thing Weds, but I definitely
don't want to wait longer than that, if it's not ready by then, we just
freeze anyway. But if you want to suggest sooner we can discuss.

Andrew

Re: M3 Freeze

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

2008/8/7 Aidan Skinner <ai...@apache.org>:
> On Thu, Aug 7, 2008 at 11:31 AM, Andrew Stitcher <as...@redhat.com> wrote:
>
>> I do think however that it would be worth holding M3 for a few days (say
>> no more than 3) if it takes Steve a little longer than that. I know this
>> could be regarded as the thin end of the wedge, but this the first
>> significant platform port of the C++ broker and things were bound to
>> show up. However IMO it would be a significant extra for M3 so worth
>> waiting just a short while for.
>
> I'm okay with this going in if guys you are. :)
>
> - Aidan
> --
> Apache Qpid - World Domination through Advanced Message Queueing
> http://cwiki.apache.org/qpid
> "Nine-tenths of wisdom consists in being wise in time." - Theodore Roosevelt

Are you suggesting holding the freeze till Monday as 'Last thing
Friday' == 'First thing Monday'?

Martin

-- 
Martin Ritchie

Re: M3 Freeze

[Aidan Skinner <ai...@apache.org>]

On Thu, Aug 7, 2008 at 11:31 AM, Andrew Stitcher <as...@redhat.com> wrote:

> I do think however that it would be worth holding M3 for a few days (say
> no more than 3) if it takes Steve a little longer than that. I know this
> could be regarded as the thin end of the wedge, but this the first
> significant platform port of the C++ broker and things were bound to
> show up. However IMO it would be a significant extra for M3 so worth
> waiting just a short while for.

I'm okay with this going in if guys you are. :)

- Aidan
-- 
Apache Qpid - World Domination through Advanced Message Queueing
http://cwiki.apache.org/qpid
"Nine-tenths of wisdom consists in being wise in time." - Theodore Roosevelt

Re: M3 Freeze

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

On Tue, 2008-08-05 at 18:01 +0100, Andrew Stitcher wrote:
> On Tue, 2008-08-05 at 15:09 +0100, Aidan Skinner wrote:
> > On Tue, Aug 5, 2008 at 2:49 PM, Steve Huston <sh...@riverace.com> wrote:
> > 
> > >> Gentle reminder that barring catastrophe, freeze is on the 8th, and
> > >> then it's a couple of weeks of stabalisation.
> > >
> > > Is there a way that QPID-1209 (Port to Windows) can be included before
> > > the freeze? This is important to me, and I'll help any way I can. I've
> > > set up autobuilds of trunk and windows branches on RHEL 4 nightly and
> > > the results are identical (with and without the windows changes).
> > 
> > I'm not sure who's reviewing that, I don't know enough (~0) about the
> > C++ side of things to offer an opinion I'm afraid, I guess Alan or
> > Gordon may be in a better position?
> 
> I'm reviewing these changes.

I've sent some review notes to Steve, most of which are small things and
I hope we can get it sorted to go into M3.

I do think however that it would be worth holding M3 for a few days (say
no more than 3) if it takes Steve a little longer than that. I know this
could be regarded as the thin end of the wedge, but this the first
significant platform port of the C++ broker and things were bound to
show up. However IMO it would be a significant extra for M3 so worth
waiting just a short while for.

Andrew

> 
> Andrew
> 
> 

Re: M3 Freeze

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

On Tue, 2008-08-05 at 15:09 +0100, Aidan Skinner wrote:
> On Tue, Aug 5, 2008 at 2:49 PM, Steve Huston <sh...@riverace.com> wrote:
> 
> >> Gentle reminder that barring catastrophe, freeze is on the 8th, and
> >> then it's a couple of weeks of stabalisation.
> >
> > Is there a way that QPID-1209 (Port to Windows) can be included before
> > the freeze? This is important to me, and I'll help any way I can. I've
> > set up autobuilds of trunk and windows branches on RHEL 4 nightly and
> > the results are identical (with and without the windows changes).
> 
> I'm not sure who's reviewing that, I don't know enough (~0) about the
> C++ side of things to offer an opinion I'm afraid, I guess Alan or
> Gordon may be in a better position?

I'm reviewing these changes.

Andrew

Re: M3 Freeze

[Carl Trieloff <cc...@redhat.com>]

> I'm not sure who's reviewing that, I don't know enough (~0) about the
> C++ side of things to offer an opinion I'm afraid, I guess Alan or
> Gordon may be in a better position?
>
>   

I think Andrew has taken the JIRA to merge it, I know he has been merging
the Solaris port -- Comments Andrew...

Carl.

Re: M3 Freeze

[Aidan Skinner <ai...@apache.org>]

On Tue, Aug 5, 2008 at 2:49 PM, Steve Huston <sh...@riverace.com> wrote:

>> Gentle reminder that barring catastrophe, freeze is on the 8th, and
>> then it's a couple of weeks of stabalisation.
>
> Is there a way that QPID-1209 (Port to Windows) can be included before
> the freeze? This is important to me, and I'll help any way I can. I've
> set up autobuilds of trunk and windows branches on RHEL 4 nightly and
> the results are identical (with and without the windows changes).

I'm not sure who's reviewing that, I don't know enough (~0) about the
C++ side of things to offer an opinion I'm afraid, I guess Alan or
Gordon may be in a better position?

- Aidan
-- 
Apache Qpid - World Domination through Advanced Message Queueing
http://cwiki.apache.org/qpid
"Nine-tenths of wisdom consists in being wise in time." - Theodore Roosevelt

RE: M3 Freeze

[Steve Huston <sh...@riverace.com>]

> Gentle reminder that barring catastrophe, freeze is on the 8th, and
> then it's a couple of weeks of stabalisation.

Is there a way that QPID-1209 (Port to Windows) can be included before
the freeze? This is important to me, and I'll help any way I can. I've
set up autobuilds of trunk and windows branches on RHEL 4 nightly and
the results are identical (with and without the windows changes).

I hope to get the broker changes in before the freeze as well
(QPID-1209 gets the C++ client going on Windows).

Thanks,
-Steve