You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Carl Trieloff <cc...@redhat.com> on 2008/06/13 17:00:21 UTC
M3 and some community clean-up
I think it might be time to start becoming more concrete on the M3
release. So far a few people have edited this
for M3: http://cwiki.apache.org/qpid/roadmap.html
I have updated with what we have done so far, and a good part is
completed. Can we hash out on this thread and
get M3 more concrete. i.e. are we going to wait for Ruby to support
0-10 before we cut M3, or will we be willing
to cut it with Java, JMS, C++ and .NET clients?
I have also moved the windows and solaris ports up into the M3 category,
as I believe those working on them want to
get them done ASAP.
I also think there are a bunch of smaller things people want to get in,
we should get these into JIRA. We also have
this comment: "Transparent 0.8/0.9/.10 support in the Java broker (might
need to be M4)" I think we need to become
concrete on what all we want to get done of the Java broker for M3.
Also, do we want to replace MINA with the IO transport on 0-8 and 0-10
Java client on trunk? What we do on the broker
is probably a longer discussion and longer term thing.
Finally, the JIRA for M3:
http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310520&fixfor=12312117
Well, lets just say it needs some clean-up. I can identify a bunch of
stuff that has been done but is not closed etc. We should
maybe setup a call, or tag team the list of items and make sure we have
what we want in the list for M3, and close out the
crud.
Maybe we open a bridge on the 19th or 20th for everyone that can join
and we do a M3 JIRA clean-up party... thoughts
Carl.
Re: M3 and some community clean-up
Posted by Rajith Attapattu <ra...@gmail.com>.
On Tue, Jun 17, 2008 at 12:19 PM, Aidan Skinner <ai...@apache.org> wrote:
> On Tue, Jun 17, 2008 at 4:23 PM, Gordon Sim <gs...@redhat.com> wrote:
>
> > I certainly agree with the timeboxing approach in general. My one concern
> is
> > the interoperability or lack thereof between the components of a release.
> A
> > plan for achieving that in some form would be good to reach, even if it
> goes
> > out past M3.
>
Agreed, this has created confusion among our users.
People often wonder what release to use etc.
The interop matrix on the download page (
http://cwiki.apache.org/qpid/download.html) is quite complex.
We need to avoid this going forward. At the minimum all components within a
release should interop between each other.
Regards,
Rajith
Re: M3 and some community clean-up
Posted by Gordon Sim <gs...@redhat.com>.
Aidan Skinner wrote:
> Release early, release often.
You've convinced me and assuaged my doubts!
RE: M3 and some community clean-up
Posted by Steve Huston <sh...@riverace.com>.
> > I think that it will be at least another 3 months before we
> have the Java
> > broker up to the same point.
> >
> > Therefore I am thinking that a 0-10 based release with the
> > components that are at that level now makes a lot of sense.
> >
> > This is a release we can then point users at if they want
> > 0-10 / the C++
> > broker rather than pointing them at the moving (unstable)
> > target that is trunk.
> >
>
>
> Yes this is a valid point.
I think so too, FWIW.
> After having a chat with Gordon I am now convinced that more
> releases will
> help bring the focus we need to get to the state where we
> ideally want be.
> Also if I am not mistaken the folks who are doing the
> windows/solaris ports
> would like to have the work in a release ASAP.
That is correct, at least for me and Windows... Solaris is probably
ahead of Windows.
-Steve
Re: M3 and some community clean-up
Posted by Rajith Attapattu <ra...@gmail.com>.
>
> I think that it will be at least another 3 months before we have the Java
> broker up to the same point.
>
> Therefore I am thinking that a 0-10 based release with the components that
> are at that level now makes a lot of sense.
>
> This is a release we can then point users at if they want 0-10 / the C++
> broker rather than pointing them at the moving (unstable) target that is
> trunk.
>
Yes this is a valid point.
After having a chat with Gordon I am now convinced that more releases will
help bring the focus we need to get to the state where we ideally want be.
Also if I am not mistaken the folks who are doing the windows/solaris ports
would like to have the work in a release ASAP.
>
> -- Rob
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
Re: M3 and some community clean-up
Posted by Aidan Skinner <ai...@apache.org>.
On Thu, Jun 19, 2008 at 10:27 AM, Arnaud Simon <as...@redhat.com> wrote:
> We should also start making a kind of planning. For example, I am
> volunteering for implementing .Net client 0.10 support. That should be
> ready for M3.1 (assuming we release M3 very soon).
That would be *awesome* if we could get that done. :)
> As we need a 8 weeks release process are we looking at this kind of
> agenda:
>
> -- week 26 Feature freeze + 6 weeks fix bugs
> -- week 32 fix Freeze + 2 weeks fix critical bugs
> -- week 34 Release M3
>
> I believe we can shorten this release process (as a lot of testing has
> already been done on this code) by immediately starting the "fix Freeze"
> phase. We would then target a M3 release for week 28. We could then
> target M3.1 for early September.
I think we should have a couple more weeks before feature freeze to
get the c++ broker ports in, and a few other bits and pieces. I also
don't think we've defined our procedures for this tightly enough yet.
I'd suggest something like weeks 29, 35 and 37, with freezes on
Wednesdays and releases on Thursdays?
> Note that I believe that the 6 weeks "fix bugs" could be shorten,
> especially if we want to release more often.
I think that's a good, and achieveable goal, but I don't think it's
likely to happen this time around. We'd really need to have things
like Cruise Control up and running for the full lifecycle, and a more
focussed development effort for that to work. It's definately
something to aim for though, particularly if we work with having trunk
being always releasable in mind.
- Aidan
--
aim/y!:aidans42 g:aidan.skinner@gmail.com
http://aidan.skinner.me.uk/
"We belong to nobody and nobody belongs to us. We don't even belong to
each other."
Re: M3 and some community clean-up
Posted by Arnaud Simon <as...@redhat.com>.
On Wed, 2008-06-18 at 22:39 +0100, Robert Greig wrote:
> 2008/6/18 Robert Godfrey <ro...@gmail.com>:
> OK, so are we saying that we should release M3 as a "0-10 release", do
> it soon, and only include those components that are close to
> supporting 0-10 today (i.e. mostly done, just getting bug fixes etc).
> This means C++ broker and client, java client and python client. M3
> would specifically exclude the ruby client, .NET client and java
> broker?
>
> That sounds sensible to me - I completely agree that it would be great
> to get a 0-10 release of AMQP out there. I do think that this will
> require careful documentation to avoid confusing users (and potential
> users).
I am +100 with that
We should also start making a kind of planning. For example, I am
volunteering for implementing .Net client 0.10 support. That should be
ready for M3.1 (assuming we release M3 very soon).
As we need a 8 weeks release process are we looking at this kind of
agenda:
-- week 26 Feature freeze + 6 weeks fix bugs
-- week 32 fix Freeze + 2 weeks fix critical bugs
-- week 34 Release M3
I believe we can shorten this release process (as a lot of testing has
already been done on this code) by immediately starting the "fix Freeze"
phase. We would then target a M3 release for week 28. We could then
target M3.1 for early September.
Note that I believe that the 6 weeks "fix bugs" could be shorten,
especially if we want to release more often.
Arnaud
Re: M3 and some community clean-up
Posted by Robert Greig <ro...@gmail.com>.
2008/6/19 Aidan Skinner <ai...@apache.org>:
> I think this is a really bad idea, and I'm quite strongly opposed to
> it.I think we should be releasing everything, but clearly documenting
> what doesn't and doesn't work and why, and making sure that stuff that
> doesn't work doesn't work in a humane, clear manner. Possibly with
> comedy unhappy Simpsons error messages.
OK, if you want to release everything you have to be able to document
to users why the C++ client doesn't talkt to the Java broker (or
whatever combinations don't work). What is the advantage to our users
of releasing everything? If we ignore resource constraints for a
moment, would you want M3 to interoperate between all languages? What
are the reasons a user would want to use an M3 java broker?
RG
Re: M3 and some community clean-up
Posted by Aidan Skinner <ai...@apache.org>.
On Wed, Jun 18, 2008 at 10:39 PM, Robert Greig <ro...@gmail.com> wrote:
> OK, so are we saying that we should release M3 as a "0-10 release", do
> it soon, and only include those components that are close to
Kinda (although marketing was never my strong point), maybe, no, in
that order. :)
> supporting 0-10 today (i.e. mostly done, just getting bug fixes etc).
> This means C++ broker and client, java client and python client. M3
> would specifically exclude the ruby client, .NET client and java
> broker?
I think this is a really bad idea, and I'm quite strongly opposed to
it.I think we should be releasing everything, but clearly documenting
what doesn't and doesn't work and why, and making sure that stuff that
doesn't work doesn't work in a humane, clear manner. Possibly with
comedy unhappy Simpsons error messages.
> Is it realistic to say that M3 C++ broker should include only solaris
> and linux support, or do people think that the Windows port is close
> to being ready? Having a Windows binary would be terrific but I also
I'd set a date for it and see what's ready and take that. I'd like to
keep trunk open for commits at every point as I don't want to hamper
progress on stuff for the sake of the release.
> buy the release often approach and maybe an M3.1 done soon after M3
> would be an option.
I suspect we probably will want to do this, if only for bug fixes. New
platform support might be a bit large to take in a point release, but
it depends on how invasive the changes are.
- Aidan
--
aim/y!:aidans42 g:aidan.skinner@gmail.com
http://aidan.skinner.me.uk/
"We belong to nobody and nobody belongs to us. We don't even belong to
each other."
Re: M3 and some community clean-up
Posted by Robert Greig <ro...@gmail.com>.
2008/6/18 Robert Godfrey <ro...@gmail.com>:
> My view is that I believe the C++ guys have done a very good job of getting
> that broker to be stable and at 0-10, and we also have got the C++, Java and
> Python clients into a state where they interoperate with that broker. i
> believe that certain organisations even believe that the code on trunk is
> good enough to make a comercial release out of it ;-)
>
> I think that it will be at least another 3 months before we have the Java
> broker up to the same point.
>
> Therefore I am thinking that a 0-10 based release with the components that
> are at that level now makes a lot of sense.
OK, so are we saying that we should release M3 as a "0-10 release", do
it soon, and only include those components that are close to
supporting 0-10 today (i.e. mostly done, just getting bug fixes etc).
This means C++ broker and client, java client and python client. M3
would specifically exclude the ruby client, .NET client and java
broker?
That sounds sensible to me - I completely agree that it would be great
to get a 0-10 release of AMQP out there. I do think that this will
require careful documentation to avoid confusing users (and potential
users).
Is it realistic to say that M3 C++ broker should include only solaris
and linux support, or do people think that the Windows port is close
to being ready? Having a Windows binary would be terrific but I also
buy the release often approach and maybe an M3.1 done soon after M3
would be an option.
RG
Re: M3 and some community clean-up
Posted by Robert Godfrey <ro...@gmail.com>.
2008/6/18 Rajith Attapattu <ra...@gmail.com>:
> >
> >
> >
> > Adding 0-10 support to the Java broker will take Some Time, and I'd
> > like to get a release out this year. ;) Ideally 2.
>
>
> Yep this is not a trivial excercise.
> But Rafi has done a very good job in having common stack that could be
> pluggable to the java broker.
> So perhaps we should evaluate and see how long this might take.
> Rob is doing some refactoring on the java broker so he may have a much
> better idea on this.
>
My view is that I believe the C++ guys have done a very good job of getting
that broker to be stable and at 0-10, and we also have got the C++, Java and
Python clients into a state where they interoperate with that broker. i
believe that certain organisations even believe that the code on trunk is
good enough to make a comercial release out of it ;-)
I think that it will be at least another 3 months before we have the Java
broker up to the same point.
Therefore I am thinking that a 0-10 based release with the components that
are at that level now makes a lot of sense.
This is a release we can then point users at if they want 0-10 / the C++
broker rather than pointing them at the moving (unstable) target that is
trunk.
-- Rob
Re: M3 and some community clean-up
Posted by Rajith Attapattu <ra...@gmail.com>.
>
>
>
> Adding 0-10 support to the Java broker will take Some Time, and I'd
> like to get a release out this year. ;) Ideally 2.
Yep this is not a trivial excercise.
But Rafi has done a very good job in having common stack that could be
pluggable to the java broker.
So perhaps we should evaluate and see how long this might take.
Rob is doing some refactoring on the java broker so he may have a much
better idea on this.
>
>
> > I think from an end user POV what is important is that when we make the
> 0-10
> > release all clients and brokers work with each other.
>
> 1. I don't think M3 has to be 'the 0-10 release'
> 2. Having all the clients talk is a more realistic, seperate
> proposition from "everything speaks 0-10"
> 3. I don't think M3 has to be that release either, although it would be
> nice.
>
> > IMO even if it takes time, we should aim to do this for M3.
> > Once we achive this baseline then we can do more frequent releases to
> cover
> > bug fixes/enhancements etc.
>
> I don't see what value holding our code on trunk has. We need to do
> more frequent releases, full stop. We keep finding reasons not to
> release until this, that or the other are done, which is somethign
> that all software projects share in common - people have an urge to
> focus on the shiney newness, rather than delivering actual product.
>
> Release early, release often.
>
I certainly believe in the above mantra.
But I am worried that we may end up with a lot of releases that don't have
interop between the language components.
IMO releases that don't interop doesn't have much value from an AMQP POV.
So far we have done 3 releases and none have shown the promise that we have
touted to deliver.
How long do we have to go before we get our act together.
I think we should bite the bullet and get it right this time and then start
doing quartely releases.
> > The key value proposition of AMQP is interoperability and if we don't aim
> > for that (at least with our own releases) we are not making full use of
> > AMQP.
>
> It is, we should and we're not. I don't disagree with any of that, and
> I think we should be doing more testing with the other AMQP
> implementations and aiming for full, seemless interop there as well.
>
> I just don't think that it's necessary to hold up our next release
> until then, provided it's clearly documented.
>
>
> - Aidan
> --
> aim/y!:aidans42 g:aidan.skinner@gmail.com <g%...@gmail.com>
> http://aidan.skinner.me.uk/
> "We belong to nobody and nobody belongs to us. We don't even belong to
> each other."
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
Re: M3 and some community clean-up
Posted by Aidan Skinner <ai...@apache.org>.
On Wed, Jun 18, 2008 at 4:29 PM, Rajith Attapattu <ra...@gmail.com> wrote:
> On Tue, Jun 17, 2008 at 5:18 PM, Aidan Skinner <ai...@apache.org> wrote:
>
>> On Tue, Jun 17, 2008 at 5:38 PM, Gordon Sim <gs...@redhat.com> wrote:
>>
>> > Perhaps even that is over ambitious for M3 though, depending on the dates
>> > chosen. I guess my question is whether there is benefit in setting those
>> > dates such that we can improve this matrix for M3 or whether an earlier
>> M3
>> > is warranted.
>>
>> Personally, I'd like to get M3 out soonish, given it's our first
>> release from trunk for a while (cough) and I'm concerned about stuff
>> rotting there (cough, cough). I could be convinced updating the
>> clients would be worth it if it could be done quickly(ish), but I'd
>> tend towards getting M3 out and everybody working together on trunk
>> before hacking 0-10 into .Net. I don't know enough about the Ruby
>> client to have a feel for how quickly that could be done, IIRC it's
>> quite thin and close to the spec so might be substantially easier.
>>
>
> Aidan if we do this, then again we will end up with the Java broker and
> .NET client lagging behind.
> This will add further to the confusion.
Adding 0-10 support to the Java broker will take Some Time, and I'd
like to get a release out this year. ;) Ideally 2.
> I think from an end user POV what is important is that when we make the 0-10
> release all clients and brokers work with each other.
1. I don't think M3 has to be 'the 0-10 release'
2. Having all the clients talk is a more realistic, seperate
proposition from "everything speaks 0-10"
3. I don't think M3 has to be that release either, although it would be nice.
> IMO even if it takes time, we should aim to do this for M3.
> Once we achive this baseline then we can do more frequent releases to cover
> bug fixes/enhancements etc.
I don't see what value holding our code on trunk has. We need to do
more frequent releases, full stop. We keep finding reasons not to
release until this, that or the other are done, which is somethign
that all software projects share in common - people have an urge to
focus on the shiney newness, rather than delivering actual product.
Release early, release often.
> The key value proposition of AMQP is interoperability and if we don't aim
> for that (at least with our own releases) we are not making full use of
> AMQP.
It is, we should and we're not. I don't disagree with any of that, and
I think we should be doing more testing with the other AMQP
implementations and aiming for full, seemless interop there as well.
I just don't think that it's necessary to hold up our next release
until then, provided it's clearly documented.
- Aidan
--
aim/y!:aidans42 g:aidan.skinner@gmail.com
http://aidan.skinner.me.uk/
"We belong to nobody and nobody belongs to us. We don't even belong to
each other."
Re: M3 and some community clean-up
Posted by Rajith Attapattu <ra...@gmail.com>.
On Tue, Jun 17, 2008 at 5:18 PM, Aidan Skinner <ai...@apache.org> wrote:
> On Tue, Jun 17, 2008 at 5:38 PM, Gordon Sim <gs...@redhat.com> wrote:
>
> > Perhaps even that is over ambitious for M3 though, depending on the dates
> > chosen. I guess my question is whether there is benefit in setting those
> > dates such that we can improve this matrix for M3 or whether an earlier
> M3
> > is warranted.
>
> Personally, I'd like to get M3 out soonish, given it's our first
> release from trunk for a while (cough) and I'm concerned about stuff
> rotting there (cough, cough). I could be convinced updating the
> clients would be worth it if it could be done quickly(ish), but I'd
> tend towards getting M3 out and everybody working together on trunk
> before hacking 0-10 into .Net. I don't know enough about the Ruby
> client to have a feel for how quickly that could be done, IIRC it's
> quite thin and close to the spec so might be substantially easier.
>
Aidan if we do this, then again we will end up with the Java broker and
.NET client lagging behind.
This will add further to the confusion.
I think from an end user POV what is important is that when we make the 0-10
release all clients and brokers work with each other.
IMO even if it takes time, we should aim to do this for M3.
Once we achive this baseline then we can do more frequent releases to cover
bug fixes/enhancements etc.
The key value proposition of AMQP is interoperability and if we don't aim
for that (at least with our own releases) we are not making full use of
AMQP.
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
Re: M3 and some community clean-up
Posted by Aidan Skinner <ai...@apache.org>.
On Tue, Jun 17, 2008 at 5:38 PM, Gordon Sim <gs...@redhat.com> wrote:
> Perhaps even that is over ambitious for M3 though, depending on the dates
> chosen. I guess my question is whether there is benefit in setting those
> dates such that we can improve this matrix for M3 or whether an earlier M3
> is warranted.
Personally, I'd like to get M3 out soonish, given it's our first
release from trunk for a while (cough) and I'm concerned about stuff
rotting there (cough, cough). I could be convinced updating the
clients would be worth it if it could be done quickly(ish), but I'd
tend towards getting M3 out and everybody working together on trunk
before hacking 0-10 into .Net. I don't know enough about the Ruby
client to have a feel for how quickly that could be done, IIRC it's
quite thin and close to the spec so might be substantially easier.
- AIdan
--
aim/y!:aidans42 g:aidan.skinner@gmail.com
http://aidan.skinner.me.uk/
"We belong to nobody and nobody belongs to us. We don't even belong to
each other."
Re: M3 and some community clean-up
Posted by Gordon Sim <gs...@redhat.com>.
Couple of corrections (ruby not yet on 0-10, python supports older
protocols as well):
Client/Broker Java(0-8,0-9) C++ (0-10)
C++ (0-10) X Y
Ruby (0-8,0-9) Y X
Java (0-8,0-9,0-10) Y Y
.Net (0-8) Y X
Python (0-8,0-9,0-10) Y Y
Upgrading ruby and .net might be the first step, particularly if that
can be done without losing support for 0-8/0-9. The only gap in the
matrix then would be the c++ client which would not work against the
java broker.
Perhaps even that is over ambitious for M3 though, depending on the
dates chosen. I guess my question is whether there is benefit in setting
those dates such that we can improve this matrix for M3 or whether an
earlier M3 is warranted.
Re: M3 and some community clean-up
Posted by Aidan Skinner <ai...@apache.org>.
On Tue, Jun 17, 2008 at 4:23 PM, Gordon Sim <gs...@redhat.com> wrote:
> I certainly agree with the timeboxing approach in general. My one concern is
> the interoperability or lack thereof between the components of a release. A
> plan for achieving that in some form would be good to reach, even if it goes
> out past M3.
AFAIK, the current supportable interop matrix looks like this:
Client/Broker Java(0-8,0-9) C++ (0-10)
C++ (0-10) X Y
Ruby (0-10) X Y
Java (0-8,0-9,0-10) Y Y
.Net (0-8) Y X
Python (0-10) X Y
(Gmail may have knackered my tabling here, couldn't figure out how to
get a fixed font)
with a caveat that the Java client on trunk is a little busted
regarding protocol negotiation, but that should be quite fixable for
M3.
I would also like to get more coverage with that, making the .Net and
the Java broker speak 0-10 would seem the obvious next steps and would
fill both columns with Y. That's a sizeable chunk of work,
particularly for the broker though, and I'd be surprised if it could
be fitted into the sort of M3 timeframe we're talking about.
- Aidan
--
aim/y!:aidans42 g:aidan.skinner@gmail.com
http://aidan.skinner.me.uk/
"We belong to nobody and nobody belongs to us. We don't even belong to
each other."
Re: M3 and some community clean-up
Posted by Gordon Sim <gs...@redhat.com>.
Aidan Skinner wrote:
> On Fri, Jun 13, 2008 at 4:00 PM, Carl Trieloff <cc...@redhat.com> wrote:
>
>> I have updated with what we have done so far, and a good part is completed.
>> Can we hash out on this thread and
>> get M3 more concrete. i.e. are we going to wait for Ruby to support 0-10
>> before we cut M3, or will we be willing
>> to cut it with Java, JMS, C++ and .NET clients?
>
> We've previously agreed to do time-boxed releases, which I think is
> pretty crucial. We've kind of let it slip recently, but I think
> getting an M3 out at an agreed point in time, with clearly defined
> feature, bug fix and hard freezes is a better tack to take than trying
> to define M3 by features.
I certainly agree with the timeboxing approach in general. My one
concern is the interoperability or lack thereof between the components
of a release. A plan for achieving that in some form would be good to
reach, even if it goes out past M3.
Re: M3 and some community clean-up
Posted by Aidan Skinner <ai...@apache.org>.
On Fri, Jun 13, 2008 at 4:27 PM, Carl Trieloff <cc...@redhat.com> wrote:
> Aidan Skinner wrote:
> Time box is good/better. The trunk is quite good currently. If we take this
> route
> do we want to declare trunk open for say 4 more weeks, than we call that the
> freeze
> date for M3? 4 weeks being a random number I pulled from the air.
That sounds like a plan to me, I'm not sure about 4 weeks more on
trunk, that would put us releasing around the end of August, but I'm
sure others will want to weigh in on this.
I'd also like to discuss a slightly different source management
process from last time (one that keeps trunk open for hacking at all
times), but let's talk about that once a release manager's been
volunteered since it will mainly affect them.
> Sounds good. I would however like to clean JIRA up a bit regardless to make
> it easier for
> those new on the project.
Oh, we are sorely in need of a bug day or similar. Partychat is
probably the place to do it rather than phone though, those things get
interminable and there's rarely more than one or two people invovled
at once.
- Aidan
--
aim/y!:aidans42 g:aidan.skinner@gmail.com
http://aidan.skinner.me.uk/
"We belong to nobody and nobody belongs to us. We don't even belong to
each other."
Re: M3 and some community clean-up
Posted by Carl Trieloff <cc...@redhat.com>.
Aidan Skinner wrote:
> On Fri, Jun 13, 2008 at 4:00 PM, Carl Trieloff <cc...@redhat.com> wrote:
>
>
>> I have updated with what we have done so far, and a good part is completed.
>> Can we hash out on this thread and
>> get M3 more concrete. i.e. are we going to wait for Ruby to support 0-10
>> before we cut M3, or will we be willing
>> to cut it with Java, JMS, C++ and .NET clients?
>>
>
> We've previously agreed to do time-boxed releases, which I think is
> pretty crucial. We've kind of let it slip recently, but I think
> getting an M3 out at an agreed point in time, with clearly defined
> feature, bug fix and hard freezes is a better tack to take than trying
> to define M3 by features.
>
> Having said that, by the previous timelines agreed we'd be entering
> feature freeze right about now, and releasing in a little over a month
> by my reckoning, which is clearly not going to happen.
>
Time box is good/better. The trunk is quite good currently. If we take
this route
do we want to declare trunk open for say 4 more weeks, than we call that
the freeze
date for M3? 4 weeks being a random number I pulled from the air.
Thoughts.
>
>> Well, lets just say it needs some clean-up. I can identify a bunch of stuff
>> that has been done but is not closed etc. We should
>> maybe setup a call, or tag team the list of items and make sure we have what
>> we want in the list for M3, and close out the
>> crud.
>>
>
> Cleaning up Jira is definately something we need to do, it's the
> proverbial den of scum and villany atm. As I said above though, I'm
> resistant to defining M3 as a feature list. There's some stuff which
> is currently targetted for it which is just unrealistic, but I'd
> rather do something like:
>
> 1. agree dates and designate a release manager
> 2. move stuff which is just not going to make it out of M3
> 3. hack
> ------ Feature freeze ---- (Release - 6 weeks?)
> 4. move features which haven't made it into the future
> 5. fix bugs
> ---- Fix freeze ---- (Release - 2 weeks?)
> 6. move non-critical fixes into the future
> 7. fix the critical things
> --- Release --- (Release)
>
>
Sounds good. I would however like to clean JIRA up a bit regardless to
make it easier for
those new on the project.
Carl.
Re: M3 and some community clean-up
Posted by Aidan Skinner <ai...@apache.org>.
And, on a related note, I'm thinking about cutting an M2.1.1 release
from the M2.1.x. branch since there's been some nice bug fixing going
on there recently. Thoughts?
- Aidan
--
aim/y!:aidans42 g:aidan.skinner@gmail.com
http://aidan.skinner.me.uk/
"We belong to nobody and nobody belongs to us. We don't even belong to
each other."
Re: M3 and some community clean-up
Posted by Aidan Skinner <ai...@apache.org>.
On Fri, Jun 13, 2008 at 4:00 PM, Carl Trieloff <cc...@redhat.com> wrote:
> I have updated with what we have done so far, and a good part is completed.
> Can we hash out on this thread and
> get M3 more concrete. i.e. are we going to wait for Ruby to support 0-10
> before we cut M3, or will we be willing
> to cut it with Java, JMS, C++ and .NET clients?
We've previously agreed to do time-boxed releases, which I think is
pretty crucial. We've kind of let it slip recently, but I think
getting an M3 out at an agreed point in time, with clearly defined
feature, bug fix and hard freezes is a better tack to take than trying
to define M3 by features.
Having said that, by the previous timelines agreed we'd be entering
feature freeze right about now, and releasing in a little over a month
by my reckoning, which is clearly not going to happen.
> Well, lets just say it needs some clean-up. I can identify a bunch of stuff
> that has been done but is not closed etc. We should
> maybe setup a call, or tag team the list of items and make sure we have what
> we want in the list for M3, and close out the
> crud.
Cleaning up Jira is definately something we need to do, it's the
proverbial den of scum and villany atm. As I said above though, I'm
resistant to defining M3 as a feature list. There's some stuff which
is currently targetted for it which is just unrealistic, but I'd
rather do something like:
1. agree dates and designate a release manager
2. move stuff which is just not going to make it out of M3
3. hack
------ Feature freeze ---- (Release - 6 weeks?)
4. move features which haven't made it into the future
5. fix bugs
---- Fix freeze ---- (Release - 2 weeks?)
6. move non-critical fixes into the future
7. fix the critical things
--- Release --- (Release)
- Aidan
--
aim/y!:aidans42 g:aidan.skinner@gmail.com
http://aidan.skinner.me.uk/
"We belong to nobody and nobody belongs to us. We don't even belong to
each other."
RE: M3 and some community clean-up
Posted by Steve Huston <sh...@riverace.com>.
Hi Carl,
> I have also moved the windows and solaris ports up into the
> M3 category,
> as I believe those working on them want to get them done ASAP.
Yes, that's correct. From the forces pushing me, it's mandatory.
-Steve