[haiku-development] Re: Request for vote for next release naming

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Tue, 11 Feb 2014 13:17:27 +0100

On 02/11/2014 12:23 PM, Stephan Aßmus wrote:
Because you are saying we need an exact list of features we still want
to include, to know whether we can call the next release Beta or not.

I'm not sure where our misunderstanding lies. First of all, I think we should name the release according to the technical phase we're in. I.e. if we want to call it beta, we should actually reach the beta phase. I understand some want to call the release beta for marketing reasons although it would technically be an alpha. When I'm referring to "beta" here I mean the technical term.

But what you are saying now seems to suggest we could basically declare
"bug fixing mode" at any point in time, and then upon looking at each
issue or bug, one would have to judge the potential effects and then
either fix the bug or not (or call off the release). Why did we need the
initial "exact list" then?

To me the beta phase is entered when the product has become feature complete. During the beta phase no new features are (scheduled to be) added (below the bug/feature fuzziness threshold). That means, if we want certain features in the final release, they must be implemented before the beta phase, or conversely, we won't enter the beta phase before they have been implemented. So we need that feature list to decide when we enter the beta phase, since entering the beta phase changes the development process (separate branch, only bug fixes being applied).

If, during the beta phase, an issue considered a blocker for the final release turns out to require a fix with potentially major side effects, we can still reevaluate whether it should be considered a blocker, or whether we pull the complete feature the issue belongs to (if possible), or whether we fix the issue and consider delaying the release to iron out the bugs newly introduced.

I don't think this contingency disagrees with having a feature list in the first place.

I agree a list would be helpful. But "exact" seems to be completely up
to interpretation.

I never said "exact", only "detailed". ATM the feature list with respect to PM has no detail at all. There are large enough subfeatures (I listed some earlier) that could be implemented or could be postponed. If I asked you whether you consider PM ready for R1, you'd probably point out some of these subfeatures as must-haves. So I think it only makes sense to put them on the list in the first place.

CU, Ingo


Other related posts: