[haiku] Re: Defining R1 Features (was Re: Will the WebKit browser be ready for Haiku R1 final?)
- From: Ryan Leavengood <leavengood@xxxxxxxxx>
- To: haiku@xxxxxxxxxxxxx
- Date: Mon, 12 Oct 2009 23:52:30 -0400
On Mon, Oct 12, 2009 at 11:11 PM, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
>
> 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.
I think this makes a lot of sense. So consider me convinced. I
certainly like the idea of shorter release cycles, something I'm used
to from the Ruby community. I think having the Locale Kit as an
experimental API is fine, but only if it can be made so without too
much work. It sounds like more work is needed on that than I thought.
> 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.
Fair enough. I'm just worried that if we don't define something at all
we will still see a bunch of half-baked alternatives like you
described above. It is sort of damned if you do and damned if you
don't situation.
I also think this could lead to various "distros" being created with
their own packaging system, each of which would most likely be
incompatible with each other. We can do what we can to discourage
this, but I suspect it would still happen. Even if they can't call
themselves Haiku, they could still fracture the community or otherwise
lead to unwanted results.
But I do agree that trying to create a really good packaging and
updating system is not trivial and trying to do so before the R1
release will definitely cause a big delay. But on a positive note
there is an alternative, which would be to package updates into
executable packages like the old BeOS updates, and this could maybe
even be used to bootstrap another updater if we created a good one
before we were ready for an R1.5 or whatever point release.
> Not sure which you have in mind and how much those are.
Mainly the stuff in aldeck's Tracker refactor branch.
> Well sure, but that requires people to actually write/improve those drivers.
> That's nothing everyone is able/willing to do.
As I will explain more in the email (which I am still working on), I
was mainly referring to diagnostics and improving the cases when
existing drivers fail to make it easier for user's to report problems
and for us to fix them.
--
Regards,
Ryan
Other related posts:
