[haiku] Re: Defining R1 Features (was Re: Will the WebKit browser be ready for Haiku R1 final?)

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku@xxxxxxxxxxxxx
  • Date: Tue, 13 Oct 2009 11:11:43 +0800

On 2009-10-12 at 16:46:14 [+0800], Oliver Tappe <zooey@xxxxxxxxxxxxxxx> wrote:
> On 2009-10-12 at 06:55:17 [+0200], Ryan Leavengood <leavengood@xxxxxxxxx> 
> wrote:
> > On Sun, Oct 11, 2009 at 11:35 PM, Ingo Weinhold <ingo_weinhold@xxxxxx> 
> > wrote:
> > >
> > > An excellent cue to start my usual "let's define a feature set for R1"
> > > speech. We shouldn't wait and see what features are ready until R1, 
> > > because
> > > that's just the wrong way around. More an more features will creep in 
> > > this
> > > way and postpone the release further and further -- e.g. the locale 
> > > stuff is
> > > now in the trunk and thus quite likely also in R1, although I think 
> > > getting
> > > it into a polished final release shape (which IMO includes making every
> > > application, library, and add-on locale-aware) is a major task that will
> > > hold
> > > off R1 longer than necessary.
> > 
> > I think the Locale Kit should be polished up and made ready for R1 (I
> > don't think it needs much more work), but I definitely agree that
> > making everything locale friendly is a lot of work (switching
> > everything to use the layout API being the biggest thing IMO.) I don't
> > think it is critical for a first release of Haiku, and as long as the
> > infrastructure is in place (Locale Kit released and debugged) it can
> > be done gradually after the release. Plus the release would probably
> > inspire new developers to join the project, and I'm sure some would
> > help on the localization effort.
> 
> From my point of view, the locale kit has been merged into trunk in order to
> give it more *developer*-exposure, not *user*-exposure.
> I am not at all convinced that the locale kit is basically done. The 
> intention
> was to let more developers work on localizing some apps and then learn from
> that experience to improve the locale kit system (and we've already seen
> requests for changes). So I guess there's more work to do.

I haven't looked too closely, but isn't the number/date/currency formatting 
and parsing even missing or incomplete?

> So I'd say we leave the locale kit out of R1 plans and just remove the 
> Locale preflet whenever we start to prepare any beta releases.

That's an option, although it still leaves all the locale related changes to 
applications and libraries in the binaries.

> We should probably add a build setting that allows for removing locale kit
> support from the build altogether, reducing build time and likeliness of 
> build failures.

I wonder whether that is possible at all. Once an application seriously uses 
localization features I'd guess it's more than a few #ifdefs to compile it 
without localization support.


On 2009-10-12 at 12:55:17 [+0800], Ryan Leavengood <leavengood@xxxxxxxxx> 
wrote:
> On Sun, Oct 11, 2009 at 11:35 PM, Ingo Weinhold <ingo_weinhold@xxxxxx> 
> wrote:
> > An excellent cue to start my usual "let's define a feature set for R1"
> > speech. We shouldn't wait and see what features are ready until R1, 
> > because
> > that's just the wrong way around. More an more features will creep in this
> > way and postpone the release further and further -- e.g. the locale stuff 
> > is
> > now in the trunk and thus quite likely also in R1, although I think 
> > getting
> > it into a polished final release shape (which IMO includes making every
> > application, library, and add-on locale-aware) is a major task that will 
> > hold
> > off R1 longer than necessary.
> 
> I think the Locale Kit should be polished up and made ready for R1 (I
> don't think it needs much more work), but I definitely agree that
> making everything locale friendly is a lot of work (switching
> everything to use the layout API being the biggest thing IMO.) I don't
> think it is critical for a first release of Haiku, and as long as the
> infrastructure is in place (Locale Kit released and debugged) it can
> be done gradually after the release. Plus the release would probably
> inspire new developers to join the project, and I'm sure some would
> help on the localization effort.

I agree with Oliver that the locale kit is not done yet and that it will be 
quite a bit more work before it is. Moreover the plan so far has been not to 
add any major public API in R1. I'm not at all opposed to making the locale 
kit (just as the layout support) available to interested developers as 
*experimental* API, if that is possible. I believe providing new APIs as 
experimental for one or more releases is a good strategy, since without a 
good deal of feedback from developers trying to use that API it is virtually 
impossible to make it excellent. Obviously that strategy doesn't work that 
well, when releases are years apart. Which is why I generally vote for trying 
to achieve shorter release cycles, possibly by cutting features.


> > IMHO we should as soon as possible define the must-have and nice-to-have
> > feature sets for R1 and plan the roadmap to the next releases. As written 
> > a
> > few weeks ago I'd even say there are no real major must-have features
> > missing, meaning we could start with the beta release series now.
> 
> I know you may not agree, but I think an updating system and a package
> management system is needed for R1. At least some initial basic
> version of both, it doesn't have to be the perfect thing we all seem
> to want out of the gate.

I agree that those are important features (or I'm with Truls on this: a 
single feature) and I also agree that they don't have to be perfect, but I 
disagree that a basic version will do for the time being. I mean once the 
thing is officially available, it will be used. And if it doesn't cover what 
is required from a package management solution, work-arounds and alternative 
solutions will sprout. Which is exactly the situation we already have (and 
had during the lifetime of BeOS). So this doesn't gain us much, but postpones 
the release.

> I also don't consider some of the Tracker
> refactoring as features but as bugs that should also be resolved
> before release.

Not sure which you have in mind and how much those are.

> But besides that I definitely think putting a general freeze on new
> features for a few months and just focusing on bugs would be really
> useful. There are still a lot of bugs, both those that are logged in
> Trac and I suspect many more that are not.

That's the whole point of defining the feature set. Once it is implemented we 
can create the R1 branch, which will host the beta phases (and releases) and 
allow only bug fixes and small feature additions.

> I also think we need to try our best to improve the hardware driver
> situation. But I'll write another email with details on that.

Well sure, but that requires people to actually write/improve those drivers. 
That's nothing everyone is able/willing to do.

CU, Ingo

Other related posts: