[haiku-development] Re: R1alpha 2 : time to get the ball rolling ?
- From: Stephan Assmus <superstippi@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 27 Feb 2010 11:21:01 +0100
On 2010-02-27 at 11:04:27 [+0100], PulkoMandy <pulkomandy@xxxxxxxxx> wrote:
> > Having short term and long term goals is good but the focus should be
> > on Alpha 2 release. Short term should be specific, center of attention
> > and long term should be general overall.
>
> Yes, but the alpha 2 isn't a final stable release. It is only a step
> towards an R1. For alpha1, we decided on a set of things we wanted to
> include, and amongst these there was a "try out if we are capable to get a
> release out in the proper way". This included setting up wiki pages on
> trac, selecting the features, setting the date, tracking the press news
> after the release, listing the known and fixed bugs, and so on.
> Now that is done, we can plan things in a better way and each alpha or
> beta release should be a step towards R1. As a consequence, we need to
> define what R1 will be first, and then define the intermediate releases
> according to that. Of course, some changes may still happen later, but
> without a clear outline, it's likely we'll end up never releasing R1,
> because we'll keep wanting to add "nearly ready" features. We could get
> alpha2 out now, for example, but everyone agrees on waiting for wifi and
> web browser... If the same happens for R1, we'll have to wait for some
> project, then something else will be started in between, and the release
> will never come. That's why it's important to set the feature set in
> advance to know when to stop, and before being tempted of adding newer
> features :)
Well said. IMHO, we shouldn't need to worry so much about whether we can
include feature X or not in the alpha 2 release. In other projects, it
isn't so unheard of that features get pulled right before a final release.
In other words, when we include WiFi or the LocaleKit in alpha 2, even if
they are not quite ready, it doesn't mean we've made a 100% commitment to
include them in R1.
About the Locale Kit in particular. IMHO, it's an important feature, and it
stirred a lot of contribution from many people in the community. Removing
this feature, because the API is actually not ready, is - IMHO - not an
option, just for the disappointment this would cause. I know the idea is to
provide a stable platform with R1, which also means APIs that will not be
broken later. But I wonder if a compromise wouldn't work as well. For
example, we could prepare the API with regards to FBC problems, that way it
can be extended. There are many other APIs which I personally would like to
break. Like BTabView and other stuff. :-) The goal for the stable API
thingy is of course that apps written for R1 will continue to run. But we
are an open source project, and we have to work with what we are. If we
manage to keep apps running for "long enough" - that will certainly work as
well. Even in five years, we could look at the available applications, and
still deal with the situation that we have one or two applications written
for the R1 API, which are abondened but still critical to not break. This
is something to worry about in the future. Right now we can try our best to
prepare for this situation, but finishing cool features like the Locale Kit
all the way may not be in our reach. I still wouldn't throw it out because
of that. Or just because some apps remain not localized.
Best regards,
-Stephan
Other related posts:
