Proposal for a GlassElevator varient build

Haiku is mature enough now for us to start considering a GlassElevator varient build (Haiku_GE) for all the new features we would love to have but are being pushed off till after R1.
We have already added x86_64 as a supported build, (we even have a PowerPC build! :smiley: ) Why not a GlassElevator build?
This will reduce arguments and satisfy developers and community members alike that have longed for features and little niceties that are outside the scope of R1 while keeping R1 pure.
If it’s worthy but not R1 worthy, Test in GE.

It will also keep more devs ā€œin houseā€ and not looking for outside projects to satisfy their wishes. :wink:

BTW This document was written under Haiku nightly running the historical BeOS version of OpenTracker and Deskbar (thanks to x512). Totally outside the scope of R1 yet exactly the original intent of R1! It’s not ā€œcanonā€ but it’s a hell of a lot of fun! That’s what I’m talking about- Bringing the fun back to Haiku! :wink:

2 Likes

Haiku already contains many features outside of the scope of R1, and there is no problem to add any more. If you want to work on some then just do so.

Libnetservices and libnetservices2 are one example, as is the package kit, support for modern monitors, webkit etc.

7 Likes

Do you have any specific features in mind for which you have both the time and knowledge that you could make them reality now,but can’t do so because of R1 goals?
I can’t think of any.
There’s a lot happening currently,also with the huge number of GSoC applicants if they all get accepted,and a lot of that isn’t exactly part of the original R1 goals but helpful anyway.
Most stuff that would be nice to have but doesn’t get implemented right now is more due to lack of time or skills or both,not so much because it’s incompatible with R1 goals (ABI breakage).

1 Like

I was really thinking about how there is a lot of contention with the devs trying to implement stuff and it getting voted down and I thought maybe if they had a place where their ideas could be brought to life it might be inspiring for everybody and it might be fun to play with.

Pull requests getting downvoted usually means that the code doesn’t fulfill the quality standards yet or that there are bugs,not that this feature isn’t wanted at all.
Getting code into a state where it gets merged can be really frustrating sometimes,but it’s important to make sure that changes don’t break more things that they fix.

1 Like

What is supposed to be included there? Who will implement new features for that ā€œGlassElevator buildā€?

2 Likes