You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jeff Genender <jg...@savoirtech.com> on 2005/08/30 19:15:03 UTC

M5 List Closure

I want to propose that tomorrow (8/31) at midnite PDT, the list for new 
M5 features will be closed, and we can begin to agree on the final QA 
cut and M5 release date...this is with a 36:45 hour notice.

If anyone has a problem with this, then please state your preferred list 
lock down date/time.  If you cannot give a new date/time, then this 
date/time will stand.  "I don't know yet" is not acceptable ;-)

Jeff

Re: M5 List Closure - GBeanName

Posted by David Jencks <da...@yahoo.com>.
On Aug 30, 2005, at 2:20 PM, David Blevins wrote:

>
> On Aug 30, 2005, at 2:17 PM, Aaron Mulder wrote:
>
>> On Tue, 30 Aug 2005, David Blevins wrote:
>>
>>>>
>>>>     I think the full conversion of "all ObjectNames to GBeanNames 
>>>> and
>>>> all queries to GBeanQuery's" can wait for post-M5.
>>>>
>>>
>>> Ok, you're confusing me.  The message "post-M5" is exactly where I
>>> thought that conversation ended up.  What part shouldn't wait for
>>> post-M5?
>>>
>>
>> This part:
>>
>>
>>>      Uh, no.  I think we should make GBeanName satisfactory, and put
>>> all the plumbing into GBeanQuery to support the queries we want and
>>> deprecate the kernel ObjectName query methods.
>>
>
> Ok, so what we need consensus on is whether we should for M5:
>
> 1)  Complete GBeanName support and officially deprecate ObjectName use 
> and convert fully post-M5.

I'd prefer this if possible.
>
> 2)  Wait till post-M5 and do all at once.

this would be my second choice.

david jencks

>


Re: M5 List Closure - GBeanName

Posted by Dain Sundstrom <da...@iq80.com>.
On Aug 30, 2005, at 2:20 PM, David Blevins wrote:

> Ok, so what we need consensus on is whether we should for M5:
>
> 1)  Complete GBeanName support and officially deprecate ObjectName  
> use and convert fully post-M5.
>
> 2)  Wait till post-M5 and do all at once.

I vote we stick with ObjectName until Geronimo 2.0.  I see no benefit  
from this change and only destabilization.

-dain


Re: M5 List Closure - GBeanName

Posted by David Blevins <da...@visi.com>.
On Aug 30, 2005, at 2:17 PM, Aaron Mulder wrote:

> On Tue, 30 Aug 2005, David Blevins wrote:
>
>>>
>>>     I think the full conversion of "all ObjectNames to GBeanNames  
>>> and
>>> all queries to GBeanQuery's" can wait for post-M5.
>>>
>>
>> Ok, you're confusing me.  The message "post-M5" is exactly where I
>> thought that conversation ended up.  What part shouldn't wait for
>> post-M5?
>>
>
> This part:
>
>
>>      Uh, no.  I think we should make GBeanName satisfactory, and put
>> all the plumbing into GBeanQuery to support the queries we want and
>> deprecate the kernel ObjectName query methods.
>

Ok, so what we need consensus on is whether we should for M5:

1)  Complete GBeanName support and officially deprecate ObjectName  
use and convert fully post-M5.

2)  Wait till post-M5 and do all at once.


Re: M5 List Closure - GBeanName

Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Tue, 30 Aug 2005, David Blevins wrote:
> >
> >     I think the full conversion of "all ObjectNames to GBeanNames and
> > all queries to GBeanQuery's" can wait for post-M5.
> 
> Ok, you're confusing me.  The message "post-M5" is exactly where I  
> thought that conversation ended up.  What part shouldn't wait for  
> post-M5?

This part:

>      Uh, no.  I think we should make GBeanName satisfactory, and put
> all the plumbing into GBeanQuery to support the queries we want and
> deprecate the kernel ObjectName query methods.

Aaron

Re: M5 List Closure - GBeanName

Posted by David Blevins <da...@visi.com>.
On Aug 30, 2005, at 2:05 PM, Aaron Mulder wrote:

> On Tue, 30 Aug 2005, David Blevins wrote:
>
>> It seems this fizzled out into a partial agreement that this was too
>> big for this release.
>>
>> Is this ok with everyone?
>>
>
>     Uh, no.  I think we should make GBeanName satisfactory, and put
> all the plumbing into GBeanQuery to support the queries we want and
> deprecate the kernel ObjectName query methods.
>
>     I think the full conversion of "all ObjectNames to GBeanNames and
> all queries to GBeanQuery's" can wait for post-M5.

Ok, you're confusing me.  The message "post-M5" is exactly where I  
thought that conversation ended up.  What part shouldn't wait for  
post-M5?

-David

Re: M5 List Closure - GBeanName

Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Tue, 30 Aug 2005, David Blevins wrote:
> It seems this fizzled out into a partial agreement that this was too  
> big for this release.
> 
> Is this ok with everyone?

	Uh, no.  I think we should make GBeanName satisfactory, and put
all the plumbing into GBeanQuery to support the queries we want and
deprecate the kernel ObjectName query methods.

	I think the full conversion of "all ObjectNames to GBeanNames and 
all queries to GBeanQuery's" can wait for post-M5.

Aaron

Re: M5 List Closure - GBeanName

Posted by David Blevins <da...@visi.com>.
On Aug 27, 2005, at 11:41 AM, Aaron Mulder wrote:
>     How about a must have to implement GBeanName according to the
> previous notes on the mailing list?
>

On Aug 27, 2005, at 11:36 AM, Dain Sundstrom wrote:

> Does this include modifying all code to use GBeanName instead of  
> object name? [....] Finally, we have not addressed ObjectName  
> queries, which are a required component of the framework and are  
> used through the code base. [....]


On Aug 27, 2005, at 1:48 PM, Dain Sundstrom wrote:
>
> We use ObjectName pattern queries.  If we eliminate ObjectNames,  
> what will we use for queries?


On Aug 27, 2005, at 2:11 PM, Aaron Mulder wrote:
>     Interfaces and GBean Name components.  I imagine, for example, the
> GBeanQuery would take a String (interface name) and/or a Map  
> (key=value
> pairs to query on).  I guess the domain too.
>
>     Jeremy mentioned wanting to support a "query language", which
> among other things would let you specify ands and ors and so on, but I
> don't think that needs to be in the first release.
>

It seems this fizzled out into a partial agreement that this was too  
big for this release.

Is this ok with everyone?

-David




Re: M5 List Closure - Time vs Features

Posted by Jeff Genender <jg...@savoirtech.com>.
Thanks David.  everyone please respond so we can close this up.

Jeff

David Blevins wrote:
> Ok, this is just an attempt to get people to voice their expectations  
> about the release in general, not in regards to any feature or item  in 
> the release.
> 
> 1)  If we could deliver M5 in ___ weeks, I would consider that a  
> complete success.
> 
> 2)  I would not like M5 to take more than ___ weeks.

Re: M5 List Closure - Time vs Features

Posted by Jeff Genender <jg...@savoirtech.com>.

Aaron Mulder wrote:
> On Tue, 30 Aug 2005, David Blevins wrote:
> 
>>Ok, this is just an attempt to get people to voice their expectations  
>>about the release in general, not in regards to any feature or item  
>>in the release.
>>
>>1)  If we could deliver M5 in _5_ weeks, I would consider that a  
>>complete success.
>>
>>2)  I would not like M5 to take more than _8_ weeks.
> 
> 
> Basis for calculation: I would like to release 1.0 by ApacheCon
> (mid-Decembmer, 15 weeks) if at all possible.  I figure at most half them
> time between now and then should be spent on M5.  But in truth, I'd like
> at least 1 more release between M5 and final.  :)
> 
> If for some reason we can't get 1.0 out by ApacheCon, I'd like to have a
> 1.0 bug-fix-only beta release & branch by then.  In other words, a stable
> platform for documentation.  No great secret there.  :)

You mean a release candidate? ;-)

> 
> Aaron

Re: M5 List Closure - Time vs Features

Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Tue, 30 Aug 2005, David Blevins wrote:
> Ok, this is just an attempt to get people to voice their expectations  
> about the release in general, not in regards to any feature or item  
> in the release.
> 
> 1)  If we could deliver M5 in _5_ weeks, I would consider that a  
> complete success.
> 
> 2)  I would not like M5 to take more than _8_ weeks.

Basis for calculation: I would like to release 1.0 by ApacheCon
(mid-Decembmer, 15 weeks) if at all possible.  I figure at most half them
time between now and then should be spent on M5.  But in truth, I'd like
at least 1 more release between M5 and final.  :)

If for some reason we can't get 1.0 out by ApacheCon, I'd like to have a
1.0 bug-fix-only beta release & branch by then.  In other words, a stable
platform for documentation.  No great secret there.  :)

Aaron

Re: M5 List Closure - Time vs Features

Posted by "Geir Magnusson Jr." <ge...@apache.org>.
2, 3

On Aug 30, 2005, at 5:05 PM, David Blevins wrote:

> Ok, this is just an attempt to get people to voice their  
> expectations about the release in general, not in regards to any  
> feature or item in the release.
>
> 1)  If we could deliver M5 in ___ weeks, I would consider that a  
> complete success.
>
> 2)  I would not like M5 to take more than ___ weeks.
>
>

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org



Re: M5 List Closure - Time vs Features

Posted by David Jencks <da...@yahoo.com>.
On Aug 30, 2005, at 2:05 PM, David Blevins wrote:

> Ok, this is just an attempt to get people to voice their expectations 
> about the release in general, not in regards to any feature or item in 
> the release.
>
> 1)  If we could deliver M5 in __2_ weeks, I would consider that a 
> complete success.
>
> 2)  I would not like M5 to take more than __2_ weeks.
>
>

david ("overly optimistic") jencks


Re: M5 List Closure - Time vs Features

Posted by Dain Sundstrom <da...@iq80.com>.
On Aug 30, 2005, at 4:24 PM, Bruce Snyder wrote:

> On 8/30/05, David Blevins <da...@visi.com> wrote:
>
>
>> 1)  If we could deliver M5 in _2__ weeks, I would consider that a
>> complete success.
>>
>> 2)  I would not like M5 to take more than _3__ weeks.
>>
>
> I don't think that taking any longer than three weeks is necessary. We
> don't need to fit everything into M5. We can have an M6 and M7 if
> necessary. In fact, I'd rather see more drops with smaller
> additions/changes than less drops with larger additions/changes.

+1 Couldn't have said it better myself

-dain

Re: M5 List Closure - Time vs Features

Posted by Bruce Snyder <br...@gmail.com>.
On 8/31/05, Gianny Damour <gi...@optusnet.com.au> wrote:
> On 31/08/2005 7:05 AM, David Blevins wrote:
> 
> > Ok, this is just an attempt to get people to voice their expectations
> > about the release in general, not in regards to any feature or item
> > in the release.
> >
> > 1)  If we could deliver M5 in _3__ weeks, I would consider that a
> > complete success.
> >
> > 2)  I would not like M5 to take more than _4__ weeks.
> 
> 
> M4 was released 4 weeks ago and I think that it should be great to have
> a release every 7 weeks, in general. This may be broken-down into a
> couple of days up-front to plan what people want in the new release
> (JIRA allocation), 5 weeks to implement what has been planned and 1 week
> to cut it (QA with TCK tests).

Please note that Jeff's original message regarding M5 went out on 24
Aug, seven days ago, i.e., it may not be prudent to think that the
planning stage will only take a couple of days.

> On 31/08/2005 9:24 AM, Bruce Snyder wrote:
> 
> >On 8/30/05, David Blevins <da...@visi.com> wrote:
> >
> >
> >
> >>1)  If we could deliver M5 in _2__ weeks, I would consider that a
> >>complete success.
> >>
> >>2)  I would not like M5 to take more than _3__ weeks.
> >>
> >>
> >
> >I don't think that taking any longer than three weeks is necessary. We
> >don't need to fit everything into M5. We can have an M6 and M7 if
> >necessary. In fact, I'd rather see more drops with smaller
> >additions/changes than less drops with larger additions/changes.
> >
> >Bruce
> >
> >
> I think that everyone agree :).  Also, this raises related questions:
> what should be the ideal duration of an iteration? does this duration
> depends on the features? Or, is the duration fixed and the features,
> which have been planned and not implemented, simply rescheduled?

IMO, we should be taking a more realistic perspective when marking
issues for a particular release. This would save the time of debating
what should and should not be included in any given release.

Bruce 
-- 
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'

The Castor Project
http://www.castor.org/

Apache Geronimo
http://geronimo.apache.org/

Re: M5 List Closure - Time vs Features

Posted by Gianny Damour <gi...@optusnet.com.au>.
On 31/08/2005 7:05 AM, David Blevins wrote:

> Ok, this is just an attempt to get people to voice their expectations  
> about the release in general, not in regards to any feature or item  
> in the release.
>
> 1)  If we could deliver M5 in _3__ weeks, I would consider that a  
> complete success.
>
> 2)  I would not like M5 to take more than _4__ weeks.


M4 was released 4 weeks ago and I think that it should be great to have 
a release every 7 weeks, in general. This may be broken-down into a 
couple of days up-front to plan what people want in the new release 
(JIRA allocation), 5 weeks to implement what has been planned and 1 week 
to cut it (QA with TCK tests).


On 31/08/2005 9:24 AM, Bruce Snyder wrote:

>On 8/30/05, David Blevins <da...@visi.com> wrote:
>
>  
>
>>1)  If we could deliver M5 in _2__ weeks, I would consider that a
>>complete success.
>>
>>2)  I would not like M5 to take more than _3__ weeks.
>>    
>>
>
>I don't think that taking any longer than three weeks is necessary. We
>don't need to fit everything into M5. We can have an M6 and M7 if
>necessary. In fact, I'd rather see more drops with smaller
>additions/changes than less drops with larger additions/changes.
>
>Bruce 
>  
>
I think that everyone agree :).  Also, this raises related questions: 
what should be the ideal duration of an iteration? does this duration 
depends on the features? Or, is the duration fixed and the features, 
which have been planned and not implemented, simply rescheduled?

Thanks,
Gianny



Re: M5 List Closure - Time vs Features

Posted by David Blevins <da...@visi.com>.
On Aug 30, 2005, at 4:24 PM, Bruce Snyder wrote:

> On 8/30/05, David Blevins <da...@visi.com> wrote:
>
>
>> 1)  If we could deliver M5 in _2__ weeks, I would consider that a
>> complete success.
>>
>> 2)  I would not like M5 to take more than _3__ weeks.
>>
>
> I don't think that taking any longer than three weeks is necessary. We
> don't need to fit everything into M5. We can have an M6 and M7 if
> necessary. In fact, I'd rather see more drops with smaller
> additions/changes than less drops with larger additions/changes.
>

+1  It's all about momentum at this stage in the game.

David

Re: M5 List Closure - Time vs Features

Posted by Bruce Snyder <br...@gmail.com>.
On 8/30/05, David Blevins <da...@visi.com> wrote:

> 1)  If we could deliver M5 in _2__ weeks, I would consider that a
> complete success.
> 
> 2)  I would not like M5 to take more than _3__ weeks.

I don't think that taking any longer than three weeks is necessary. We
don't need to fit everything into M5. We can have an M6 and M7 if
necessary. In fact, I'd rather see more drops with smaller
additions/changes than less drops with larger additions/changes.

Bruce 
-- 
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'

The Castor Project
http://www.castor.org/

Apache Geronimo
http://geronimo.apache.org/

Re: M5 List Closure - Time vs Features

Posted by David Blevins <da...@visi.com>.
Ok, this is just an attempt to get people to voice their expectations  
about the release in general, not in regards to any feature or item  
in the release.

1)  If we could deliver M5 in ___ weeks, I would consider that a  
complete success.

2)  I would not like M5 to take more than ___ weeks.


Re: M5 List Closure - J2EE Certification

Posted by Jeff Genender <jg...@savoirtech.com>.

Aaron Mulder wrote:
> 	Has anyone taken a stab at running the TCK on Tomcat yet?  If not, 
> I think it's going to be hard to agree on a sensible ETA.

No...I can start it...but I really need some people to step up and help 
out here ;-)

Jeff

> 
> Aaron
> 
> On Tue, 30 Aug 2005, David Blevins wrote:
> 
>>There was some discussion in M4 on possibly J2EE certifying that  
>>release or maybe M5.  Can we get a clear consensus that:
>>
>>  1) this is what we want to do with M5
>>
>>  2) what is the ideal timeframe for completing that (in weeks, don't  
>>say soon).
>>
>>
>>
>>
>>

Re: M5 List Closure - J2EE Certification

Posted by David Blevins <da...@visi.com>.
On Aug 30, 2005, at 1:13 PM, Aaron Mulder wrote:

>     Has anyone taken a stab at running the TCK on Tomcat yet?  If not,
> I think it's going to be hard to agree on a sensible ETA.

Not looking for a sensible ETA, more of a "how long are we willing to  
allow for it, ideally" kind of thing.

For example, post M3 we always thought the ETA for passing the CTS  
was weeks away when it turned out to be 12 months away.  We should  
have been explicit with our expectations of how long we were willing  
to give it before reconsidering the goal.  Not saying we should  
reconsider the goal now, just define what "ASAP" or "soon" should be  
ideally.

-David

> Aaron
>
> On Tue, 30 Aug 2005, David Blevins wrote:
>
>> There was some discussion in M4 on possibly J2EE certifying that
>> release or maybe M5.  Can we get a clear consensus that:
>>
>>   1) this is what we want to do with M5
>>
>>   2) what is the ideal timeframe for completing that (in weeks, don't
>> say soon).
>>
>>
>>
>>
>>
>>
>
>


Re: M5 List Closure - J2EE Certification

Posted by Aaron Mulder <am...@alumni.princeton.edu>.
	Has anyone taken a stab at running the TCK on Tomcat yet?  If not, 
I think it's going to be hard to agree on a sensible ETA.

Aaron

On Tue, 30 Aug 2005, David Blevins wrote:
> There was some discussion in M4 on possibly J2EE certifying that  
> release or maybe M5.  Can we get a clear consensus that:
> 
>   1) this is what we want to do with M5
> 
>   2) what is the ideal timeframe for completing that (in weeks, don't  
> say soon).
> 
> 
> 
> 
> 

Re: M5 List Closure - J2EE Certification

Posted by David Blevins <da...@visi.com>.
On Aug 30, 2005, at 1:17 PM, Geir Magnusson Jr. wrote:
>>
>>  2) what is the ideal timeframe for completing that (in weeks,  
>> don't say soon).
>>
>>
>
> I'll try to do the research re what is involved beyond the  
> automated test suite.

Great.  We can make a list of steps required and factor it in.

I phrased the question badly, though, sorry.  My response to Aaron  
clarifies.

-David



Re: M5 List Closure - J2EE Certification

Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Aug 30, 2005, at 3:54 PM, David Blevins wrote:

> There was some discussion in M4 on possibly J2EE certifying that  
> release or maybe M5.  Can we get a clear consensus that:
>
>  1) this is what we want to do with M5

I would be happy with that.

>
>  2) what is the ideal timeframe for completing that (in weeks,  
> don't say soon).
>

I'll try to do the research re what is involved beyond the automated  
test suite.

geir


>
>
>
>

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org



Re: M5 List Closure - J2EE Certification

Posted by David Blevins <da...@visi.com>.
There was some discussion in M4 on possibly J2EE certifying that  
release or maybe M5.  Can we get a clear consensus that:

  1) this is what we want to do with M5

  2) what is the ideal timeframe for completing that (in weeks, don't  
say soon).





Re: M5 List Closure - Console Support

Posted by Geir Magnusson Jr <ge...@4quarters.com>.
thanks for doing this.  Would it make sense to start separate  
threads?  my mailer treats them all as the same thread...

On Aug 30, 2005, at 4:14 PM, David Blevins wrote:

> Some discussion has occurred on how we want to role out the console  
> in M5.
>
> On Aug 26, 2005, at 5:54 PM, Aaron Mulder wrote:
>
>>     So I updated the console status on the Wiki:
>>
>> http://wiki.apache.org/geronimo/Web_Console
>>
>>     Basically, there's a lot of work yet to go.  I've put some work
>> into web server, logging, and JMS server portlets so far, and Joe's
>> pitched in a bit as well, but I don't think I'd really say there's  
>> any
>> page there that's fully working and satisfactory.
>>
>>     As far as M5 goes, I think we'll do what we do in the time frame
>> we end up having.  I think it's going to be a "technology preview" in
>> every sense.  I don't think it makes sense to hold M5 until the  
>> console is
>> "done" or to try to cut down the console to the stuff that  
>> actually works
>> right.  Still, it wouldn't break my heart if M5 took a while so we  
>> could
>> get more done on the console.  :)
>>
>>
>
> On Aug 26, 2005, at 7:02 PM, Aaron Mulder wrote:
>
>>     Well, OK, after talking about this a bit more, it seems like
>> there's some interest in picking certain features we'd defintiely  
>> like to
>> have in the console for M5.
>>
>
>
> On Aug 27, 2005, at 11:15 AM, Dain Sundstrom wrote:
>
>
>> I think we should clearly state that the console is a "Technology  
>> Preview", and point the users to JIRA to file feature requests.
>>
>>
>
> I assume there would be no arguments against clearly communicating  
> (via labeling, some page in the console, release notes, or all of  
> the above and more) that the console is a "Technology Preview."
>
> So what looks like what still is open for consensus is do we:
>
> 1) Take the time pick certain features and hold the release till  
> they are done.
>
> 2) Do what we do in the time frame we end up having.
>
>

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geir@optonline.net



Re: M5 List Closure - Console Support

Posted by David Blevins <da...@visi.com>.
Some discussion has occurred on how we want to role out the console  
in M5.

On Aug 26, 2005, at 5:54 PM, Aaron Mulder wrote:
>     So I updated the console status on the Wiki:
>
> http://wiki.apache.org/geronimo/Web_Console
>
>     Basically, there's a lot of work yet to go.  I've put some work
> into web server, logging, and JMS server portlets so far, and Joe's
> pitched in a bit as well, but I don't think I'd really say there's any
> page there that's fully working and satisfactory.
>
>     As far as M5 goes, I think we'll do what we do in the time frame
> we end up having.  I think it's going to be a "technology preview" in
> every sense.  I don't think it makes sense to hold M5 until the  
> console is
> "done" or to try to cut down the console to the stuff that actually  
> works
> right.  Still, it wouldn't break my heart if M5 took a while so we  
> could
> get more done on the console.  :)
>

On Aug 26, 2005, at 7:02 PM, Aaron Mulder wrote:
>     Well, OK, after talking about this a bit more, it seems like
> there's some interest in picking certain features we'd defintiely  
> like to
> have in the console for M5.


On Aug 27, 2005, at 11:15 AM, Dain Sundstrom wrote:

> I think we should clearly state that the console is a "Technology  
> Preview", and point the users to JIRA to file feature requests.
>

I assume there would be no arguments against clearly communicating  
(via labeling, some page in the console, release notes, or all of the  
above and more) that the console is a "Technology Preview."

So what looks like what still is open for consensus is do we:

1) Take the time pick certain features and hold the release till they  
are done.

2) Do what we do in the time frame we end up having.


Re: M5 List Closure

Posted by David Blevins <da...@visi.com>.
On Aug 30, 2005, at 10:15 AM, Jeff Genender wrote:

> I want to propose that tomorrow (8/31) at midnite PDT, the list for  
> new M5 features will be closed, and we can begin to agree on the  
> final QA cut and M5 release date...this is with a 36:45 hour notice.
>
> If anyone has a problem with this, then please state your preferred  
> list lock down date/time.  If you cannot give a new date/time, then  
> this date/time will stand.  "I don't know yet" is not acceptable ;-)
>

I noticed a few things in the first M5 thread that didn't really  
close.  Going to split them out into sub-threads and we can reach  
explicit consensus.

-David