[haiku-development] Re: Beta1 and R1 release plan
- From: Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 04 Nov 2014 09:39:23 +0100
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 :-)
Plus, this would require everyone to stay around forever. That also is a
quite unlikely scenario in my book.
You are still assuming that the R2 release is "atomic".
Every release is atomic :-)
Of course there will be alphas and betas. That doesn't change a thing
about the value of being binary compatible, though.
Anyway, I think we both have expressed our thoughts, and there is not
much to add on this topic.
[...]
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.
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.
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.
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?
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.
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.
ATM in Linux a new release is only really needed when it supports that
new hardware you own. It's different for Haiku, as we still have to
deliver so many missing functionality.
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? :-)
Bye,
Axel.
Other related posts:
