I thank the OP for their appraisal of the situation and, whilst not being an insider who is bale to verify the pull requests and backlogs, feel that comments on the role of a roadmap ring true.
I have made no secret in this forum of my admiration of the progress of Genode, and the way that project formulates and then executes on its roadmaps is quite instructive. Link to roadmap as well as more nebulous set of future “challenges” (I suppose the kids call them “side quests” these days) is on the About page. These are not massive documents but give an idea of where the project sees itself heading. They do however, along with a release schedule you can set your watch to, give a sense of progress and momentum that we do not see in Haiku. I would like to see similar in Haiku’s own - currently very terse - roadmap.
To follow the motoring metaphor invited by mention of a roadmap, its lack of detail means that many of us casual users - wanting to know if support for this or that feature is forthcoming - can feel in the forums like a child in the backseat asking “are we nearly there yet” every five minutes in a multi-hour car journey.
There’s a few more features I’d like to see before R1. One is session support, that is saving the state of all open applications and windows on quit and then restoring them when reopened. Without this feature stack & tile is not very useful because stacks don’t survive a reboot.
Yes, yes and yes very nice roadmap or suggestions…
This sounds so promising and positiv, I missed that much, thank you!
There have not been much discussions on what we will do after R1. There are things we will not do before R1 (such as breaking compatibility with BeOS, and even then, we have scaled down our goals quite a bit), but that doesn’t mean we have to start working on these things immediately after R1 is out.
I don’t think that’s the case. What’s the point in having things in the R1 milestone if we can just decide to move them out at any time? We should rather put more effort in triaging the tickets and keeping in R1 the things that we consider essential to R1.
Personally I would rather prefer that we consider the OS “done” after R1 and we can move on to writing apps, and just doing maintenance and small improvements (as we already do, really). An R2 with a “let’s rewrite everything differently” seems like a waste of time (and R1 is already a human lifetime scale project).
We may allow ourselves some minimal changes that do require breaking API and ABI, and a little bit of cleanup. But I don’t expect R2 to be such a major thing in terms of development efforts. More like, a lot of boring recompiling of all apps and minor fixes. Hopefully done in a way that R1 apps continue running on R2, while new apps can use the new ABI, and eventually we can drop R1 apps support sometime later.
You make it soud as if someone is driving the car and knowing where it’s going. I don’t think that’s the case. We’re all (users, developers, contributors, it doens’t matter) pulling things each in our own direction. And if a lot of people are pulling it in the “let’s sit in the backseat and ask if we’re nearly there” direction, not a lot of thing will happen.
So, get involved however you can. Write a bugreport about a problem you have. Pick an old bug report and see if you can reproduce it. Pick a changeset from Gerrit that no one has touched and see if you can make the changes requested in review comments. Point out when these requested changes are unreasonable and out of scope of what the change is meant to solve. Help keep haikuports recipes up to date. Rate applications in HaikuDepot. Help with translations. Write some documentation. Vote for the tickets you’d rather see solved soon on Trac. Participate in the discussions about the future of Haiku. All these things will get us somewhere.
It might cause more problems, than help, but I’d love to see a central place, where developers leave suggestions for help. When a dev bumps into it, and thinks “I can’t get to that right now” it could be posted/tagged to that central location. Maybe no one will get to it, before the dev does; but it could “potentially” create a capability based hierarchical team. Those that love Haiku, could make it a labor of love. Please laugh at me “hard” if this already exists.
See APIChangesOnCompatibilityDrop on dev wiki for documentation on what changes we plan to do immediately after R1 is released. Of course there will still be an R1 branch that we can continue to update separately.
I have thought about this for a while and we can create a libhaiku.so that mirrors libbe.so and go from there. R2 apps would link libhaiku.so and R1 apps link libbe.so. Then we would be free to alter libhaiku.so to break the ABI all we want.
Sure if a ticket is R1 and a blocker or we decide they are showstoppers then that holds up release. Anything we decide to not fix will get chucked in the R1.1 milestone. It is unreasonable to expect us to fix every single bug in the bug tracker before releasing R1. At some point we have to release with a list of bugs that we deem acceptable.
We want to update the APIs first so that we can write new apps using those new APIs. We don’t want to write R2 apps on the R1 API that we’ve been saddled with so far. We want to fix all the things that we can’t fix right now because of ABI constraints. With those issues fixed, we then migrate everything we want to to the new API or write replacements.
Maybe the good approach about this thread is : move to the “Ask Things” to “Do Things” mindset for Haiku?
If Haiku releases are slow because core developers have limited free time, what I can suggest is changing the mindset from requesting things to contributing things
The community can directly help reduce the workload of the core developers.
The actual questions are:
As a core developer what tasks would actually save time? ie which tasks could contributors take over to free your time?
Are there specific areas where help is most urgently needed? It must be categorized by complexity for sure
What small tasks could newcomers do that would still be useful?
Possibles areas:
Development
Documentation
Testing
Translation and localization
Website updates
Community support: helping newcomers on forums
Maybe what is missing today is to communicate again and again that way to the community, and to put pointer to where the contribution wishlist is ? (maybe it exists but it had not been updated since a long time?)
There should be enough volunteers, I think, would can help that way.
For new comers : “Do not ask what Haiku can do for you, but ask what you can do for Haiku”
Because you can proactively pick tasks instead of waiting for developers to do all the things
Because every small contribution helps.
Because it will create a healthier relationship between you and developers.
I am well aware of this page; but as far as I know, there is no plan to do that “immediately after R1”. It’s just “there is no way to do it before R1”. My plans for after R1 is to continue things as usual and work on R1.1. If there is an R2 branch where none of my apps run, I will have no interest in that until it is relased.
Isn’t that what the bugtracker and gerrit backlog are for? And also the several pages on the website in the “contributing” category? And if these pages are not good enough, then improving them can be put on the list of things to improve as well.
When I created the R1.1 milestone, I went over the entire list and moved about 300 tickets there. I think no one has used the R1.1 milestone since. I assume my triaging is not perfect, but despite repeated discussions about this, nothing is ever moved from R1 to R1.1. So, what is it? Either these bugs really need to pe fixed for R1 and there isn’t that much to move off the milestone, or maybe no one actually cares about reaching R1 and we’re fine with the estimate of 18 years of work left if things continue at the present pace.
For new comers, I’d add that it starts by filling detailed tickets in proper bug trackers.
Haiku version and architecture, steps to reproduce the problem are a must.
And some of them are with last updates few years ago. I’m not sure if most newcomers aware that this page exist. Part of the tasks are classified into R1.1 or unscheduled tasks, can we put some beta 6 tasks in, and remove those unscheduled tasks?
There are plans to do this immediately after R1 that’s the whole point of on compatibility drop, we’re no longer constrained. Unless you’re saying that R2 is supposed to be binary compatible with R1 ABI but I was under the impression that once R1 is released we would be free to break the ABI in all the ways we’d like to but are currently unable to do.
Once everything runs again then R2 branch will be released and it will be the new stable target going forwards and then you’ll be interested in running it. Before that it will be in development and you’ll be expected to run on R1. We don’t plan to break the entire system on once, it will be done piecemeal, but we do plan on breaking binary compatibility in R2.
Of course we haven’t used this milestone as we’re optimistic that we’ll be able to fix all of the bugs in the R1 milestone by the time R1 is to be released. However, if we get to the point that we want to release R1 and there’s still unfixed bugs in the R1 milestone and we deem those bugs to be acceptable or at least not blocking release, then we can move them to the R1.1 or R2 milestone where appropriate or we can close them with status “won’t fix”.
We are free to do it, but it doesn’t need to be the first thing we do. Especially if we relase R1 without solving a lot of the tickets in the milestone, personally I’d rather continue on fixing the bugs and keep the existing apps running. And if R1 gets succesful, there will be lot of apps using the “old” APIs that we may not want to break. So, we’ll have to be careful about how we do that migration, how we keep the R1 API/ABI working until R2 is released, etc.
It is things we have to do on the R2 roadmap, but not the things I would plan to work on first. There will surely be many other things to fix and improve as well.
I meant this, let prioritize Gerrit to Beta 6/R1 milestones ticketes. If something isnt critical part for kernel or drivers (Meaning new stuff) dont push it up on Gerrit (core focus) part . And opposite for milestone tickets of ALL versions.
Keeping an OS single-user by design isn’t a bad idea—it could make things a lot less complicated. But it’s like a shirt: eventually you might need a new one.
In that case: why not create a multi-OS environment instead of a multi-user OS? A new user could just mean a fresh Haiku instance (running like an app, the same way it would run in parallel inside the host OS).
Regarding the roadmap and Haiku R1, I’d like to remind everyone…
Be Inc. developed BeOS with the mindset of building something truly new—an out-of-the-box approach that didn’t try to fix the old mistakes the traditional way, but instead tackled them by making things work completely differently…
I like the idea of embracing single-user design going forwards. While businesses absolutely need multi-user support, home users generally do not. I know some people will not agree with this stance. We want to assume a single user of the system, but we still want process separation and privilege separation.
My thoughts on this is that we should wait until we have hypervisor support and then create some sort of virtual jail in a vm for other users or processes to isolate apps. We could also prevent apps from writing to certain directories without giving permission first.
I think that none of “APIChangesOnCompatibilityDrop” list is actually important and worth do do. It gives a little cosmetic benefits, but do not really make developing Haiku applications more easier or productive. Harm of breaking API/ABI, rebuilding/adapting existing software, maintaining multiple ABI versions compatibility is bigger.
I think there are more important things that worth API breaking changes for R2:
Changing coordinate system to use pixel corners as coordinate system origin like it is natively implemented in all major 2D rendering libraries and APIs such as AGG, Cairo, Skia, HTML5 Canvas. This will reduce confusion, fix various problems like scaling artifacts. So for example BRect(0, 0, 4, 4) will mean rectangle that occupies 4x4 pixels, not 5x5 pixels as in current Haiku implementation.
Splitting BView drawing API into separate BCanvas API. BView is currently do too much things and suffer from “god object” antipattern. Make drawing to BPicture and BBitmap not need BView, only BCanvas. Reduce combinatorial explosion of Fill|Stroke(Line|Rect|Ellipse|Path|Region)(color|gradient) into one method to draw each shape and pass fill/stroke and color/gradient as arguments or draw state.
Fix scripting to make it more safe and robust. Maybe switch to Binder and was originally made for BeOS and currently used in Android. Introduce ownership model so objects referenced by another team with scripting will be not deleted until all references will be released. Introduce connection-based protocol, so if some team that reference scripting objects will suddenly crash, it will not cause resource leak. Introduce event notification mechanism in scripting, not just method call.
Introduce some IDL language for scripting and code generation to not write protocol handling by hand.
Make optional ability to run BWindow in an arbitrary BLooper, do not force to run each window in a separate thread. Not all applications really make benefits from each window in a separate thread and it will simplify porting foreign applications.
Introduce layout markup language like YAML, so application design can be defined in declarative language instead of C++ code.
something more
This can be done without breaking compatibility with existing BeOS/Haiku applications by introducing separate API library like libbe2.so or libhaiku2.so that will also connect to the same app_server. app_server protocol is private without guaranteed stability, so it can be adjusted to introduce features that will be used only by Haiku R2 API.
