RE #3: I like it too, if we are clear what we mean by "enough people". Of
course, anyone can make a [proposal] to cut a fixpack, but only when "enough
people" (a quorum) have made the proposal should it move to a [vote]. I suppose
it will depend on the relative important of the fixes. If a vote is being
taken, it should reference a list of fixes to which the vote applies (i.e. a
simple list that one can view at once, not something that requires us to follow
links/bugIDs...), from which one could express an informed opinion.
---Rotan
-----Original Message-----
From: Heather Stephens [mailto:[EMAIL PROTECTED]
Sent: Wed 13/10/2004 20:11
To: Beehive Developers
Cc:
Subject: RE: [proposal] Beehive release strategy
NOTE: Quality/Code Tidy/etc. discussion moved to 'Beehive "Quality
Processes"' thread.
RE #2: The pitch I made is less complex than what you're suggesting. I
can see the reasons why we need to go with an extra layer of branches to
both support old releases and forge ahead on new ones. Let me take a
crack at redrawing the picture in the diagram. I will put more words
around branching vs. labeling too.
RE #3: I like this approach. Rotan? Others?
> -----Original Message-----
> From: Ken Tam
> Sent: Tuesday, October 12, 2004 2:59 PM
> To: Beehive Developers
> Subject: RE: [proposal] Beehive release strategy
>
> Overall strategy looks good. Thanks Heather!
>
> Drilling in:
<< snip >>
> 2) Can the doc be explicit about using actual subversion concepts of
> branches and tags? This would be super helpful in avoiding confusion
> over what's really going on. For example:
> a) branch for work on major (X.) releases.
> b) tag revisions within a branch for the .y.z revisions, including
> ".0.0".
>
> This implies that "minor" and "fixpack" releases are developed on the
> same branch. Depending on the scope of changes going on for "minor"
> releases, we might consider adding:
> c) branch within a major release branch for work on fixpack releases
> against released minor versions.
>
> It would be simpler to say "fixpacks only come out in the context of
the
> current minor version", but that might be too restrictive. Thoughts?
> Consider the following version number sequence:
>
> 1.0.0
> 1.0.1
> 1.1.0
>
> now, do we permit a 1.0.2? Or do we say that if you want a change to
> 1.0.1, you'll have to get it in 1.1.1?
> In the former case, we're saying that we want to allow provision (c),
> and 1.0.2 is made in a branch-of-a-branch while 1.y.z work continues
on
> a branch.
>
> 3) To speak to Rotan's point about an "unambiguous time to cut a
> fixpack", how about leaving it up to the community? If enough people
> feel that enough fixes have gone in to make it desirable to have a
> formal tag/release number tracking that collection, then they can
> propose a fixpack.
>
>
> -----Original Message-----
> From: Heather Stephens
> Sent: Tuesday, October 05, 2004 4:23 PM
> To: Beehive Developers
> Subject: RE: [proposal] Beehive release strategy
>
> Thanks for the input Rotan.
>
> My thoughts on some of your items below.
>
> Are Rotan and I really the only ones with opinions? It would
> be great to hear others' input too. *hint, hint*
>
> >> 3: If I have version X.y.z, will there be an easy way for me to
> >> determine the feature set?
>
> Yes. Good point. I think we have to have that. I'd like to
> writeup a document for our feature planning process that
> would include both how somebody could put a feature on the
> docket, how we target them to specific releases and how we
> indicate to each other that a given feature is complete and
> ready to be used. Obviously using Jira for much of this
> would really help. :)
>
> >> 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?
<< snip >>
>
> -----Original Message-----
> From: Rotan Hanrahan [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, September 21, 2004 5:21 PM
> To: [email protected]
> Subject: FW: [proposal] Beehive release strategy
>
> 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
>
>
>
>
>
>
>
