[haiku-development] Re: Beta1 and R1 release plan
- From: "Niels Sascha Reedijk" <niels.reedijk@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 04 Nov 2014 03:53:40 -0800 (PST)
Hi,
On general I agree with the statements in the discussion. In this email I argue
that we might have to tweak our view on our target audience, and at the bottom
I will outline my view on the future release discussion.
On dinsdag, nov. 4, 2014 at 9:40 a.m., Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>,
wrote:
Am 03.11.2014 18:52, schrieb Adrien Destugues:
> On Mon, Nov 03, 2014 at 05:47:36PM +0100, Axel Dörfler wrote:
> As I already said, I would much like a stable branch, from which
> releases should be made. You think it should derive from the R1 branch
> and integrate features from master whenever possible. I think we should
> instead keep master stable so we can branch out future releases from it.
> I suggest doing that by using the Gerrit flow (where changes are
> reviewed before they can be merged to master) or something similar.
That sounds far away from your original playfield proposal, which I
think is a step in the right direction :-)
I think we have different problems to solve:
- how the next releases should looks like (technically)
- define a workflow that will allow us to a) evolve quickly, and b)
still be able to to production releases
We should try to separate this in our discussion. At least I think we're
already pretty much on the same page regarding the latter :-)
I agree everybody seems to be in agreement right now.
> I don't think the crazy "release every 6 months" schedule of Ubuntu is a
> good solution at all. And, they have LTS versions, too - which is the
> only thing I would look at if I wanted a (somewhat) stable system. The
> amount of updates and fixes you get daily on an LTS install years after
> the release is a bit frightening, too.
As I said, I'm a fan of rolling releases. And I do count Haiku into
that, too. But that doesn't mean that components may need time (even a
lot of time) to evolve until they are ready for the inclusion in a
release. One thing at a time.
I agree with the concept of doing releases more often. There is a hidden cost,
in that major updates do tend to introduce new problems and issues that you
generally want to fix in a QA-process. Just how hard that is, is demonstrated
by Apple, in which the annual release schedule does seem to increase the amount
of problems in their OS’es.
Adding tot that, it might even be more challenging for us. Many of the blockers
that are in our issue tracker seem to be issues that require time and debugging
(since we are pretty much feature complete). It seems to be very difficult to
allocate resources into doing those tasks (they lie pretty dormant for a long
time).
So definitely a point of attention.
> Waiting for years for a system update is not a problem. We are talking
> about just the system here, not the whole package repository as it
> happens in Linux distributions. Using an "old" system does not mean you
> are restricted to old applications.
That certainly relieves the situation, yes, but that's still not any
different from BeOS days. You can still use BeOS R5 with current
applications. But since it's dead, almost no one develops for it anymore.
It's a mostly a psychological thing. If you have that huge piece of
software in the works, what you deliver now will not be good enough. And
let's face it, Haiku as it is now, is not up to par with other operating
systems on many fronts (power management, 3D, just to name a few). This
may not be that bad for you or me, but it's definitely a problem for many.
I would like to add that IMHO the OS-wars are over and dealt with. With it went
the market for alternative OS’es. Mobile is the new hot thing, and even there
we see that the market is about to be settled. There is a choice of two OS’es,
and I have the gut feeling that the desire to install custom roms or to
jailbreak is decreasing there as well. So I think the tinkerers have moved on
to the computers they are carrying with them all the time.
That means that Haiku will always be for a very specific group of people, a
group who is willing to put up with an alternative OS, who are willing to
invest time in the tinkering to getting things work.
And that’s okay. It makes it easier for us. It means that we can focus on this
smaller group of users and cater to their interests. This does not mean that we
cannot be ambitious to expand the user groups in future releases, it just means
that we don’t have to cater for it now.
[…]
>> Well, let's just decide this together, okay? That you maintain the R1
>> release (+ bug fixes) does not mean you have to maintain R1.1+ too, if you
>> don't like.
> I think what you call R1.1+ here is what I call R2 alphas/betas. If
> that's the case, I think there is room for both - and even a need for
> both as I explained above, to let 3rd-party developers be part of the
> design process for the APIs they will use when R2 gets out.
As I said, I'm all for iterative development, and rolling releases. Push
out features as soon as they are ready (but not any earlier, of course),
and don't work silently off the grid for years for something big.
I would argue that given the target audience I outlined above, I think that is
an audience that is willing to make the trade-off between getting the new stuff
and experiencing software breakage. We do have to focus on hardware support and
compatibility in order to not annoy them too much.
[…]
> And I'm not convinced that we can
> incrementally include features in our GCC4 API in R1 point-releases
> without breaking anything - as far as I know there are people planning
> for major changes like a complete rewrite of the Interface Kit. If we
> deploy something like this in an R1.1 release, and suddenly all existing
> gcc4 apps stop working, we can't pretend that people should have been
> using the gcc2 API - not anymore.
Why on earth should we release something that does not work? That line
of thought doesn't make any sense to me.
You actually argued that people can update their applications for GCC4
changes, and that package management cures it all. There will be alpha
and beta releases for every new point release, too. If you don't care
about binary compatibility you will always have the problem you just
outlined.
I'm trying to find a balance that keeps Haiku working, and still doesn't
cut off our user base from updates.
So far, while we are approaching each other on the workflow side of
things, we did not manage to convince either one of us on the release
side of things. I don't really have anything else to say on the matter,
so maybe we should let the other developers speak up? :-)
So here’s how I would see it:
* Haiku R1 is nearing release-quality. It needs some polishing and some support
on the side of the infrastructure, but it is about done. For us, it is the new
baseline in terms of hardware support and minimum features.
* After releasing R1 we will start to work on the next new thing. As far as I
am concerned one of the first steps is a major change in our development
platform, that is the switch to GCC4/clang/C++ 11/whatever. IMO that should be
the first and foremost goal, since it will imply in the tailwater that there
will be a cleanup of the APIs, and the apps, the kernel, and the visuals.
* We will make it one of our goals to do our best to cater for binary software
compatibility. For example, we will promise to do that for at least one major
release (R1->R2) or at least 3 years. That gives developers ample time to
update their stuff.
* Note that the last statement is a promise to put in the effort, in reality we
might have to break the compatibility partially or fully based on the reality.
I am cautious about making time-based rolling releases, I think I would prefer
the releases to be based around one or a few major features. In the tailwater
of those major features the smaller updates to applications can follow.
In a different email I will respond the workflow/Gerrit.
Regards,
N>
Other related posts:
