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:[EMAIL PROTECTED]
Sent: Tue 21/09/2004 22:16
To: Rotan Hanrahan; [EMAIL PROTECTED]
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:[EMAIL PROTECTED]
Sent: Friday, September 17, 2004 9:52 AM
To: [EMAIL PROTECTED]
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:[EMAIL PROTECTED]
Sent: 14 September 2004 00:22
To: [EMAIL PROTECTED]
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
