beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rotan Hanrahan" <Rotan.Hanra...@MobileAware.com>
Subject FW: [proposal] Beehive release strategy
Date Wed, 22 Sep 2004 00:21:11 GMT
I'm sure the Dev team would be happy to contribute additional comments on the proposed Beehive
release strategy, so as requested I'm sending "this" to "there".
---Rotan

	-----Original Message----- 
	From: Heather Stephens [mailto:heathers@bea.com] 
	Sent: Tue 21/09/2004 22:16 
	To: Rotan Hanrahan; beehive-ppmc@incubator.apache.org 
	Cc: 
	Subject: RE: [proposal] Beehive release strategy
	
	

	Hey Rotan-
	
	This is all great feedback and seem like good discussion items and
	questions for the team.  It doesn't seem like there is anything
	particularly private or sensitive in this email and so I think it would
	be great if we could have this discussion in a more public forum on
	beehive-dev.  Would you mind sending this there to open it up to the
	larger community?
	
	H.
	
	-----Original Message-----
	From: Rotan Hanrahan [mailto:Rotan.Hanrahan@MobileAware.com]
	Sent: Friday, September 17, 2004 9:52 AM
	To: beehive-ppmc@incubator.apache.org
	Subject: RE: [proposal] Beehive release strategy
	
	Quick feedback:
	
	0: Looks good.
	
	1: Is there any way to validate that a successful unit test sequence was
	executed?
	
	In effect, I'm wondering if there's a way to prevent check-in *unless*
	the tests have passed.
	
	2: Is there a code tidy process?
	
	This is a sweeper task that one or more people do. Look at code and tidy
	the comments or layout according to style rules we agree in advance.
	Ambiguous comments get referred to the author for clarification. This
	might sound like a minor task, but if we have a large community and not
	all are native speakers of the comment language (ie english) then
	someone has to make sure it is clear and makes sense. Preferably good
	coders with good communication skills. It also provides an avenue for
	contributions that may not be code mods, but would still be very useful
	to those who do the actual coding.
	
	3: If I have version X.y.z, will there be an easy way for me to
	determine the feature set?
	
	4: 'When appropriate, cut a "fix pack"...' needs clarification.
	
	Will there be a set of unambiguous criteria against which one can
	ascertain whether or not the time is 'appropriate' to cut?
	
	5: We need a stable objective quality assessment mechanism from which we
	can observe trends.
	
	For example, we could agree a hardware and o.s. reference environment,
	and then run an agreed set of tests on this platform, measurings key
	statistics as we go. Over time we will obtain some objective performance
	quality trends. We might then be able to sync a feature/bug introduction
	to a change in performance (+/-), which in turn would suggest an
	inspection of that code (to fix or to learn).
	
	
	Regards,
	---Rotan.
	
	
	-----Original Message-----
	From: Heather Stephens [mailto:heathers@bea.com]
	Sent: 14 September 2004 00:22
	To: beehive-ppmc@incubator.apache.org
	Subject: FW: [proposal] Beehive release strategy
	
	
	FYI.  Feedback appreciated.
	
	-----Original Message-----
	From: Heather Stephens
	Sent: Monday, September 13, 2004 4:20 PM
	To: Beehive Developers
	Subject: [proposal] Beehive release strategy
	
	Hi all-
	
	I've been putting some thought into a release strategy we might use for
	Beehive.  http://wiki.apache.org/beehive/Release_20Process
	
	Please take some time to review and assess it as the Beehive general
	release model.  If you would raise any concerns or suggest
	revisements/refinements on this alias for further discussion that would
	be fabulous.
	
	Timeline goal:
	9/19/04:  Close on discussion and resolve any issues
	9/20/04:  Finalize proposal and send to a vote at the PPMC
	
	Cheers.
	Heather Stephens
	
	
	
	

Mime
View raw message