The more I think about the subject I think the solution is to have a monthly version. Basically, take a nightly image that we all agree has no known bugs and simply point to it with a link, and call it the “recommended monthly” Or the “community recommended monthly edition”
If we want to get real fancy we can disable some of the extra debugging options To increase performance.
All in favor say +1 
Basically no nightly since the last beta would qualify for this.
I would say +1 
But I’m afraid that this procedure would bind more resources to manage a monthly version. And all I read shows that Haiku needs more resources.
For that I would prefer a cleanup of the download page first. And after that build a monthly version when your devs have enough time for it.
Perhaps I worded that wrong. I should say one that we all agree is stable enough for the task.
It would not take away from any devs time. In fact they would not even need to be involved unless they wanted to.
We as a community can discuss it- and review bug submissions for a chosen nightly and say that we like hrevXXXX as the our choice for the April “Monthly”
again, none of them are. that is the very essence of the nightly branch, take the continue booting bug on efi for example. certainly that isn’t something normal users should deal with. the nightlies simply aren’t and can’t be tested as stable as the betas can, just because certain revisions work for you does not mean they will for others, especially when there is actuall development… in say drivers
I don’t really understand why you wish to push users to use the explicitly expressly unstable branch so hard, saying it has worked for some users isnt really an answer to why (and it’s a bit like arguing that one can and should drive a car drunk solely because there was no accident the last time one did this)
The fact is that in practice most nightlies seem to work pretty well.
I suppose it might be that some of us (me!) are confusing improvements in the OS with improvements in applications. Web+ keeps getting better, but it would presumably work just as well on the Beta.
As a result of these discussions I am going to go back to the Beta and see whether it performs better, worse or neither than a recent nightly.
Alright, allow me to throw a dart at this “release balloon” as well…
What if… The Monthly Release only targeted a known hardware configuration. This release would be as stable as possible for this known hardware configuration and anything else would be “use at your own risk”.
What would this “known hardware configuration” be from the infinite possibilities (retro/old, modern, new)? I would suggest QEMU. Haiku already works very well in QEMU and avoids most driver issues. So besides setting up a Monthly Release, the Haiku QEMU guide could be touched up to be more friendly to new users.
The “Yearly Release” could then target physical hardware when the developers feel Haiku is ready.
What exact patch list and its order need to be applied? A lot of patches on Gerrit are confusing.
Will you buy a dozen of the same computers to send them to all persons who want to contribute to Haiku?
Haiku runs on the computers the developers test it on. Few of the problems with releases are hardware compatibility problems anyway so this wouldn’t even change a lot.
I’m not sure what you find confusing, they are all tagged bfsresize and part of a single patch series, with the last patch being this: https://review.haiku-os.org/c/haiku/+/953/8
You can see the order in the “relation chain” list here.
You can use the download → checkout button on this patch to get this branch, and then rebase it on master, if you want to try this. It comes with a “resizefs” command line tool.
I will refrain from giving a snarky answer and guess that you didn’t fully understand my post. My suggestion is to recommend using QEMU, a virtual machine, as the target of a Monthly Release. Using QEMU with a defined configuration would allow for new users and beginner users of Haiku a good first experience. It would also give developers a known baseline for a “good enough” Monthly Release. For the advanced or experienced users, they know what they are getting into if they install on bare metal.
Why QEMU instead of VirtualBox? Based on forum activity, except for network configuration, people seem to have fewer problems running Haiku in QEMU than they do with VirtualBox.
That’s great! However not everyone has the same hardware configuration of what works for the developers.
Hopefully my old laptop will agree with you once Beta 3 has been released. Regardless, I will definitely trust your observation on this matter. Considering what seems to be an increase of hardware/driver related questions in the forum over the past few months, hardware expectations could be changing or it could just be an anomaly.
How do you disable the extra D bug stuff? Since it seems a lot of users are using nightlies
By not using nightlies, disabeling the extra debug stuff would invalidate the entire point of even having nightlies for development and tesing.
There is likely a contingent of the userbase who use nightlies mainly since they get the latest changes immediately, being essentially rolling release by nature. Perhaps for them, nightlies without most of the extra debug stuff could be provided?
Again, this defeats the purpose of nightlies. We want the tech savvy users of the nightlies to help revealing the bugs introduced on the way to the next release.
One thing I would like to see more is backporting some fixes and improvements to the beta branch. If we use the beta process to work out the kinks in the release process, we should also practise this kind of hotfix/update of a current release. Maybe even leading to the mythical rolling release…
This would also keep the casual users in the loop and have them stick to the official release for longer.
Whatever the solution will be, there are still evidently a number of users who just want the latest changes as soon as possible. The reasons vary, from better HW support to getting new features or bugfixes earlier than a beta release. Something should prolly be done to cater to them, if they are discouraged to use nightlies as they are at the moment.
IMHO just providing what are essentially nightlies without debug stuff (in addition to the current ones with them) would be the fastest and easiest way to address this, especially given the resources and manpower behind the project. But if anyone’s got better ideas on how to solve this, then I’m all ears.
The deal is: you want the latest features, you get them, and in return you get to debug the latest bugs. That is already working (a lot of people found their ways to the nightly builds already). However, it should not be the “by default” route, because that’s not what a lot of users want. And by asking this on this forum, where we are talking between people already involved in some way in developing or testing Haiku, is not going to show that.
Never said anything about making it a default, just have some option for those who want it.
So, isn’t that what we already do? The nighlies are available at download.haiku-os.org, they are linked from the download page on the website, but they are not offered as an equal choice with the beta. You will find them easily if you are looking for them. No one said they should be more difficult to find than they currently are?