Gerrit backlog vs. “no roadmap”: where is Haiku actually going?

Development OS
42

We have the Trac tickets, but an ordinary Haiku user that wonders about the project cannot or will not go through those tickets to understand what’s the current status and the scope of the project.

We need something like this: Roadmap - Kdenlive

I think we will need input from @waddlesplash more than anyone else, since he’s currently the biggest contributor doing the necessary work to get us closer to a R1 release.

Aside from these, IMHO, a R1 should not happen without these:

  • A robust and safe file system, that will allow people to invest in BFS ecosystem and trust us with their actual data away from all those corporate evil companies, plus disk encryption
  • A working Media Kit, for people to be able to create and consume multimedia on Haiku sans 3D acceleration (plus an improved media player)
  • Various power saving and performance boosting functionality like sleep and support for newer CPU stuff
  • Support for all common input systems, so that people can use Haiku on their laptops

After these switching into R2 mode and laying the groundwork for for instance @X512 ‘s new App Server and the support for actual 3D acceleration for Web Kit and Media Kit would be much easier once a R1 is out.

2 Likes
43

Note that 3D acceleration, compositing and 2D rendering acceleration do not require any breaking changes to current Haiku API/ABI. Only some minor additions to BBitmap and BView.

5 Likes
44

Everyone has their personal list of what should be in R1. If we take the union of these lists, and we also factor in that new needs arise permanently, then we will never reach R1. Personally I am totally fine with that. I work on whatever I need fixed in the OS I use everyday. Everything else is not important to me, and since no one is paying me to work on it, why would I bother? Sometimes I find a problem that’s I’m not personally affected by, but that looks like a fun or inteiesting thing to solve.

I think many of the contributors work like that, and there is no interest in a roadmap. So, someone could draft one, but what’s the point? There are two possible outcomes: either contributors will continue to happily ignore it, and nothing will change. Or, people will feel forced to not work on anything else than the roadmap, and at that point it all seems like boring work that’s also unpaid, and my guess would be people will start working on uheir own apps instead of the core OS.

There’s one exception as Waddlesplash is the one developper getting paid. But even then, Haiku inc has set up their contracts in a way that they give very little input on what should be developped, and they trust the contracted people to know best what to do. Personally I think Waddlesplash is doing a great job at that recently, picking up tasks that improve stability, performance, and hardware support, which are the main things I expect to see in the R1 roadmap. And also picking up tasks that require a lot of dedicated time, that other developpers would have trouble allocating to them.

So let me phrase the question another way: have you seen Waddlesplash (the only developper who is paid for his work, and therefore the only developer from whom anyone is in a position to demand something) work on things that seem off-topic for R1? And even for other developers, I don’t think there’s that much offtopic work going on, and even when there is, it seems to be on reasonable things that do make Haiku better and appealing to more people (dark mode, high dpi support for example are definitely not on the R1 roadmap). Do you think work on these things is a waste of time? Would you like Waddlesplash to instead buy a lower resolution display just so he can work on Haiku and intentionally restrict it to worse hardware and only people with good eyesight who can use small fonts?

I think development is going in the right directions, so a more formal roadmap wouldn’t really help. Or maybe we can write down what’s happening if that makes people happy. The roadmapeis: “people work on whatever they feel is necessary, useful or fun at that moment. We collectively trust everyone to choose wisely, using their own mood, their own set of problems, and/or the ticket list on Trac shall they ever runeout of their own problms to solve. This is working great and has kept the project running for more than two decades so we have no intention of changing it.”

2 Likes
45

I think @waddlesplash is doing a great job, and has his priorities set straight for a usable Haiku. However, we have people coming-going and complaining about the status of the project, and have the impression that there is no roadmap. Except there is, which is already being worked on. A brief and plain dump of future plans for a R1 release would save a lot of time for threads like this.

Also, judging by the mailing list messages, there is no consensus among the developer team about what should the R1 be, and that’s bad IMO.

1 Like
46

Well, first two points are directly related to Haiku R1 goal about reaching BeOS R5 feature parity. BFS and Media Kit are original BeOS features and it should work at leas not worse than in BeOS (i.e. no 10+ second BFS lags, no file system corruptions, no Media Kit crashes, low latency, proper node connection/disconnection handling).

Power save and multi-language input are out of Haiku R1 scope.

7 Likes
47

There is some discussion, which is good, and how we can reach consensus (or adjust it as some people challenge the previous one).

Adjustments are obviously needed, as the goals for R1 25 years ago were different from 15 years ago and may be different again now.

And the vision has been a bit controversial from the very start, especially if the plan for R1 is to have it in another 18 years. This is because the goal of the project is to replicate BeOS, an OS that was very innovative and freshfor its time. What does “replicate” mean? If we’d work on a byte-for-byte clone, we would now be doing retrocomputing, and looking at the past. That is not what BeOS was about. So, a part of the vision for Haiku is to keep looking forward and trying fresh ideas, as BeOS did. But another part is keeping the simplicity of BeOS, and the focus on desktop systems, that is not at all a given in other operating systems these days. And everything is built on that contradiction, which gives developers some freedom to try to pull things in one direction or the other. In the last few years, we have moved a bit away from BeOS apps support, with, for example, abandoning support of binary compatibility with BeOS drivers, and rejecting some changes that would make app_server use the exact same font as BeOS for these old apps to avoid some layout issues (as several BeOS apps used hardcoded pixel sizes for everything, not taking into account the possibility of different fonts).

So it looks like, R1 may be gradually moving away from BeOS support, and that would allow to remove several items from the roadmap if/when we make it official. A few years ago it would have been unthinkable, but now, it is not what most developers care about, and few users still run BeOS apps that have not yet been rewritten or replaced (there are still a small number of apps there, but much less than there were a few years ago). So, the vision changes gradually, rather than making a big R1 release and then suddenly starting to chase completely different goals for R2. I think that’s a good thing?

48

At least make existing API mentioned in BeBook properly working that is not fully achieved yet. Even if abstract from BeOS, it is software quality problem that some public APIs are not working properly, or even cause whole OS to crash. Is it good idea to release Haiku R1 with critical bugs left?

3 Likes
49

Single user desktop system is OK, but it does need to be secure online.

It doesn’t need to be a gaming system, nor a server system.

Data security is a must.

I see Haiku as an O/S for giving old computers a new lease of life, mainly.

50

What do you mean by “data security” from OS side?

51

At this rate it will take another 18 years to fix them all and release R1 with all bugs fixed.

And still we are working on new stuff, which not necessarily a bad thing, but we are obviously introducing new bugs. Maybe we could just admit we will never be able release the R1 “we want” and just remove the beta label and just switch to a more or less fixed time based release schedule.

Our beta arent really betas anyway, because we don’t release the new beta starting from a stable branch, but always from the master. So Haiku becomes more stable in a beta release, but then the development goes on in the master, so it starts becoming unstable again, requiring now much more work to make a new release.

4 Likes
52

Huh? betas come before stable, not the other way around. This style of development is the same way the other sytems like debian or FreeBsD use.

53

That’s not what we are doing.

We don’t base beta6 on beta5. We base it on master. If we really followed the standard release process we would have been feature freezed since beta1

54

I disagree, Using a “unstable” branch and going to stable point releases seems to be the standard. Having betas does not mean we can’t rework parts of the system.

55

Let’s see…..

Haiku R1b6 roadmap mentions 35 bugs as of today.

  • 29 bugs new
  • 4 bugs assigned
  • 2 bugs reopened

In theory, squashing one bug a day brings a completion date around Dec 25th.

Earlier date is achievable if you consider bugs really in need of immediate fix versus low priority

Some bugs deal with third-party applications versus kernel or core applications.

Some bugs deal with VM issues versus actual native Live sessions (non-VM) or actual installs to hardware.

Some bugs deal with debugger issues and proper setup of debugging sessions (i.e. DWARF).

So….. maybe not look to drink the ocean when a cup of water will do?? :bird:

1 Like
56

we are already in a “more or less fixed schedule”, but we are failing at it. I would rather have a dscussion about how to improve that, in a way that it doesn’t come at a cost of extra work (like maintaining two branches) or degraded quality (something like release every year at a fixed date, no matter if there are critical bugs). How we name the releases is not really relevant there?

3 Likes
57

To be fairer, 2010 is near the birth year of some people who are taking an interest in Haiku currently.

1 Like
58

Can’t we keep all the BeOS compatibility just for x86 and move on with x86_64 to post BeOS compatibility since it’s not comatible with BeOS anyway? Anyone interested in BeOS compatibility can work on x86, and everyone else can move on to R2+?

59

The codebase is shared and the BeOS compatibility doesn’t really get in the way of anything else that much. I don’t think halving the team and working on two essentially separate codebases (for all or part of the system) is a good move.

BeOS compatibility isn’t the thing that holds us back, in most cases. And the R2 work also likely means breaking compatibility with existing Haiku apps (there will be a compatibility layer of some kind, but again, separate and independant parts of the code).

I don’t think there is so much desire to start on R2 work from anyone (neither users nor developers?) at the moment. There is still more than enough work within the goals of R1 and in other work that doesn’t involve removing BeOS compatibility

60

Well, I am working on Nvidia 3D acceleration driver and app_server_neo project that use Vulkan+Skia for 2D acceleration and optional compositing. It is technically out of R1 scope, but it do not need API/ABI breakage. Existing application binaries will run as is (except app_server decorator add-ons).

9 Likes
61

Since what is and what isn’t R1 isn’t clearly defined, how can we say there is not much desire to start on R2 work ? Moreover, from what you said, it seems like post R1 work means breaking binary compatibility, but as X512 said, there is much which can be done without breaking it.