[haiku-development] Re: Beta1 and R1 release plan
- From: Adrien Destugues <pulkomandy@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 4 Nov 2014 10:35:06 +0100
On Tue, Nov 04, 2014 at 09:39:23AM +0100, Axel Dörfler wrote:
> >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.
Sure. Wether this comes in a release called R2 or R1.1, does it really
matter? The important thing here is that there should be releases
frequent enough and bringing in the new features one after the other,
instead of one huge release every 15 years with a whole rewrite of
everything.
>
> >These problems are really getting in the way of getting the release out.
> >It is currently not possible to encode audio and video in Haiku
> >(MediaConverter will crash).
>
> I don't really see the connection. ffmpeg definitely could do that years
> ago, the problem must be on our side, anyway.
Well, yes, we could go back to ffmpeg 0.8.something, which worked, but
then we lose support for h264 and probably some other really common
video and audio formats (also for decoding).
>
> >A simple test cases of starting 5 threads
> >and having each of them do a printf will also reliably crash because our
> >libc is broken.
>
> I find that hard to believe. Could you open a bug report for that, and
> attach a test case?
There is one already, of course:
https://dev.haiku-os.org/ticket/11182
> >If we don't do the "stable R1" as I suggest it, we are going to get
> >people running on R1.x versions that are actually only of alpha quality,
> >and unsupported. We have some users still running alpha4 currently, and
> >it's a problem to them that there are no security fixes for it (for
> >heartbleed, shellshock, poodle, and probably a whole bunch more
> >problems).
>
> That's a whole different issue. If we wanted to provide an LTS version of
> Haiku, we definitely could. If you want to maintain that one, great! I just
> think it shouldn't be the default release mode, but an option for those that
> want it.
Ok, fine. Let's say we call these R1.0.x, and allow R1.1+ to be released
with new features and more changes as you suggested then.
> >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 think a stable legacy API and a well planned alpha/beta cycle is enough
support to let people update their applications to the new release
before it gets out. If someone wants to spend time on also keeping
binary compatibility, then it's even better.
If we go with a gcc2-only binary compatibility layer as originally
planned, there are many gcc4 apps that will need updating to the new
release. Having alphas and betas when making changes to the gcc4 API
sounds reasonable to me (and having people update their gcc4 apps for it
- they have been warned that the gcc4 API would change).
Now it is only a problem of finding someone with motivation and time to
keep the binary compatibility layer working in future releases. Since
everyone has either not enough motivation or not enough time, we have a
problem here. So I'm trying to think of alternatives: API-only
compatibility (still sounds reasonable to me), ignoring the problem and
breaking everything (most likely not a good idea), no compat support in
R2 but providing LTS on R1 so people can take the time it needs to
migrate their apps to the new R2 APIs (not as good as the other options,
but not as much work). If we can find someone to do the work on the
compatibility layer, then it's all fine and we don't need any of these
workarounds; but that seems a rather large "if" to me.
--
Adrien.
Other related posts:
