Haiku Beta Discussion

1

Going to move the discussion here.

Then there’s a problem there. I don’t see how even solving all the R1/beta bugs including low priority ones, which should be around twenty, will change anything in this sense. There are lots of problems in an area or another which can be cataloged in the section of the many problems.

It seems then we are still far from this idea of having a beta.

Then, is maybe that the whole idea of R1 is non viable, in contrast with the development model?

We can just have like most projects in the open source world, periodic releases with major, minor and testing versions.

I don’t see what would be for you a “stable platform”. We certainly can’t be bug free, so can you extend?

I see only confusion around. Suppose I’m going tomorrow to submit a patch for each of the R1/beta1 tickets, then what’d change?

The project will still have embarassing bugs. I suggest to focus on the blocker bugs only and release the beta one time for all.

I still don’t understand. I must be blind. Wasn’t Haiku R1 marketed to be a viable replacement for BeOS R5? It seems this goal is filled since years now.

R1 was promised to be BeOS compatible because the community wanted a solid stone to build a bright future for OpenBeOS. Now Haiku is at this point, why the project fear going forward?

Of course not. But having a release set in stone should motivate some people to advance the project. Supply better API and better support.

Why someone should build an application for an Operating System which missed to do a release for 18 years?

4 Likes
2

Hello Barret. I guess that it’s true that the original milestone of a “BeOS clone” is already done. However, if the project just replicate the functionality of the original BeOS, today, it will be lacking a lot of things that weren’t available in the 90’s, but today is a must (like USB3, WiFi, UEFI, etc.).

Besides that, some time ago there were a poll where the community was asked about what improvement have to be a “must” and what not. I guess that is in the following link:

https://dev.haiku-os.org/wiki/FutureHaiku/Features#GeneralInterestPoll

I think that a lot of the project scope to Beta was defined there.

4 Likes
3

In my eyes Haiku has significantly surpassed BeOS R5. Once the infrastructure is ready, I think Haiku is beta worthy. Yes, there are still bugs and will be bugs. But even BeOS had bugs.

2 Likes
4

I seem to have picked up in the middle of the conversation here, but if the question is “is Haiku ready for a beta release” - no! I’m speaking from what may be an antique notion of release schedules, but the way I remember it, you start with “alpha” releases, move to “beta” releases, before the final production release. These names are signals for the people who participate in them, that describe the state they can expect to find. An alpha release is a sort of sketch with everything pretty much filled in, but very likely rough edges; a beta release should be quite settled but could still have some bugs to be discovered and fixed.

“We certainly can’t be bug free” - so true. But the risk that we run with releases isn’t just the bug itself, it’s also the fix. Each time you fix a bug, you now have to reset the testing that’s been done. It’s time for a beta when you think you might be able to live with it the way it is. If it turns out you’re wrong, you fix it up and try again. When you know you can live with it, it’s time for production. There should be at least one alpha before the betas, though (and it should be clear that alpha4 from years ago is not it!)

It seems to be common use the term “stable” to mean bug-free, but another and maybe more useful meaning is, that we can depend on it not to change for a while. Some people like running the latest Haiku out of the development builds, but that’s no good for application software. If you’re doing that and you have trouble with something I wrote for the production release, I don’t want to hear about it. Not that I’m promising to release something, but you see what I’m saying, the only thing any application developer is going to want to support is a production release. We can have that production release only when it’s good enough that everyone isn’t going to desert it for the next bug fix. We can start having beta releases when we think we’re close to that point. I’m not speaking for Haiku developers, that’s just how I understand release cycles.

5

Aren’t we already advertising nightlies? At least that is what one could logically assume from the big message one is greeted with upon attempt to download the “latest” alpha. I can see having it around as a milestone comparison. But to greet new users and devs by sending them to a download page that essentially says whoops, this really isn’t the download page you probably want, but we’re going to offer this outdated version first before sending you to the download page that you’ll find more interesting and relevant? Is this what we want as a first impression? The nightlies are the closest thing we have to a stable, AND relevant release. I don’t see this in contradiction to the “we need a stable platform to attract devs and users” idea.

And don’t take wrong what I said about taking on new devs. I was trying to point out that a “when it rains it pours” scenario could lead to negative issues not immediately apparent. We definitely need more devs. But be careful what we wish for at the same time. A mass exodus from Linux could occur tomorrow. In that event, I could foresee R1 occurring next week and in a month Haiku could resemble some jumbled mess of APIs and UI and be renamed Lin-coup. I’m not excited about that possibility. :grin:

6

@un_spacyar Of course I know this poll, in fact I even voted on the user version of it, we are feature complete basing on this list :slight_smile:

1 Like
7

I think I may have to clarify my view more. The question is, how far are we going with that? There are few blocker tickets for R1/beta, even fixing those we are not going into avoiding embarassing bugs. But the whole point of the beta is being feature complete, and we are. So there should be something I don’t see in the goals that were set for this project.

GSoC is around the corner, people will begin to say “there’s GSoC let’s make the release after the summer”. So, I don’t see a sense. It seems we should rename the project Zeno OS.

1 Like
8

lol! Sorry then! :smile:

9

I think the whole Alpha/Beta/Mega-release model is archaic and impedes progress. It didn’t work well in the 90s and 2000s, and isn’t working any better. The difference is back then companies like Microsoft had to do it because the OS had to be put on floppy disks and distributed around the world. We are no longer bound by such limitations.

My thought is to release every 4 or 6 months, with a freeze on that branch 2 or 4 weeks prior to release so basic regression testing can be done (I bet there are non-dev users who will volunteer!).

After being gone for a decade+, I’ve been actively watching the forum, IRC, and the commits for the past 8 months or so. Just in that time the developers have a lot of great work! I think getting on a regular release cycle is a great way to showcase the improvements that have been done, build momentum to attract others, and keep the community engaged.

1 Like
10

I agree. That’s why I think we need an R1 and then reconsider our release model. R1 would be set in stone and be a good start to begin looking forward :slight_smile:

4 Likes
11

You guys just want an operating system for some reason of your own, or are you expecting third party developers to write and support applications, for this changing-every-six-months platform?

2 Likes
12

Haiku currently changes daily. Supporting software on a system that has a couple releases a year is much easier than trying to support software on nightly builds.

2 Likes
13

The system isn’t changing in terms of public API.

14

A r1 is in my thinking a state of haiku developent rev… In a separate source line. Changes here only bug fixes and drivers.

The standard source line for the nightlys will be alive and not change in his function.

So developers can create software on a good base. Only this way they can do a support, because they can be too much changes between the nighly builds.

15

That is the way I see things too. I dont’t mind if people are using nightlies or monthly releases or whatever. What I’m after with these R1 thing is not a release at all costs, or a sway to attract media attention, it’s to provide a fixed platform with bugfix only updates.
On one side, this will allow people to keep their applications running on that platform, and on the other, it will finally free the main development branch from that “let’s not break anything” constraint, so devs can more easily work on new features, modernizing things, etc.
In order to achieve this we need some extra work on the haikuports and package repos side, where unfortunately I can’t be of much help. Once that’s sorted out, we can create the release branch, spend some time deciding what to do with the beta1 tickets (probably not fixing them all), and then ship it.

I won’tallow GSoC to be used as an excuse for further delays. Reme@ber that in the winter we have GCI, and doing a release inthe 3 free weeks per year left isn’t going to work. Our team is still large enough to handle both GSoC and a release in parallel!

4 Likes
16

I think too, that it is a failure to see the gsoc as the way to take the project forward. I see the gsoc as a chance to bring new devs to haiku. Binding people over her project on haiku.

1 Like
17

Haiku needs to break API (and thus binary) compatibility with BeOS to move forwards.

Due to the stated goal of a binary compatible BeOS replacement, the (artificial) constraint has been placed that an R1 must be released that is BeOS compatible.

API compatibility was a great target, a perfect guide, and an amazing milestone to reach, but now that haiku is essentially there it is a wall that holds development back and stops haiku advancing. If a release isn’t made it will forever languish there, unable to break free.

1 Like
18

Can you give some example?

And what you mean by “BeOS compatible”?

19

I don’t have specific examples for particular issues that require API changes. But the question of implementing a new feature or not and whether it would break the API comes up quite frequently. Perhaps it is not a pressing issue right now in a specific instance, but it is still a perimeter that haiku cannot currently move outside of. That the Be API has both given the developers focus and will be broken after R1 are points covered well and from what I can tell agreed upon in discussions amongst both developers and users. The Be API is great, but haiku needs the freedom to be able to change it in places if necessary. If it can’t be changed because R1 is never reached, then it stifles development.

Personally I’m not looking for R1 or beta 1 because I think it will be somehow that much better than what we have already. I think that it is a great milestone and that having a standard base will attract more developers. But the biggest thing is that it will allow the project to press forwards.

By BeOS compatible I simply mean binary and API compatible, which has always been the aim for R1 as far as I know.

20

64 bit Haiku can not be binary compatible with BeOS. And this showing us that milestone can and will bend to our needs. What I want to say, just one step at the time. Just lets make working system. I think when API changes will be actually needed, they will be.

2 Likes