At last, R1/beta1 is nearly upon us. As I’ve already explained on the mailing list, only two non-“task” issues remain
in the beta1 milestone, and I have prototype solutions for both. The
buildbot and other major services have been rehabilitated and will
need only minor tweaking to handle the new branch, and mmlr has been
massaging the HaikuPorter buildmaster so that it, too, can handle the
new branch, though that work is not quite finished yet.
Excellent news Augustin. A lot of interest will be generated by R1B1 news, and lots of fresh installs will be attempted. My biggest concern on the hardware side are the following 3 items:
XHCI crashes (KDL) for USB3
HDA (unmapped audio ports) which can work if the user reboots into Haiku from another OS
UEFI boot which can be resolved with separate install image
A nice warning message on the download page should alert users about this issue.
My second concern is the 32 compatibility port for x86_64 systems (I expect most downloads to be for 64 bit system). Ideally, Jerome’s work on the compatibility layer should also make the R1B1 release, but if it cannot, then at the very least we should alert the users to know that it’s coming.
Lastly, some promotional screenshots would be nice. Screenshots for apps like LibreOffice, Blender, QtCreator etc should ease the migration to Haiku.
Having said all that, I really need to spend more time on my native Video Editor (missing audio editing and titles, however the video effects work very well using GLSL effects). My goal is to launch just before R1 final.
After such a long wait, it’s amazing to see the first beta soon to be released. A lot of great work has been done, and Haiku is in the right place to receive a lot more attention.
I also share concern about the USB3 issues - my Skylake-based PC restarts almost instantly when trying to boot from USB3, so it is plausible that others will have this kind of issue. But we can’t realistically expect a fix with the proposed timeline, and I think the Beta 1 is far more important than USB3 boot.
I can’t believe we’re so close to this milestone. Awesome!
We’ll see. I believe @pulkomandy said he’d try to devote some time to investigating XHCI. But, yeah, unlikely there will be anything truly revolutionary at this point.
Almost certainly not getting any big fixes in on this one, unless someone else steps up to the plate.
We have a WIP that should be deployed in the next few days or so to add the UEFI loader to the anyboot images.
It will not. It was already merged once and started causing too many strange issues that it’s too big a risk, so I’ve requested it not be included. I don’t know what major things it prevents one from doing – certainly running BeOS applications and 32-bit applications in general is nice, but I don’t see how it’s such a must-have…?
32 Bit compatibility adds hundreds of packages to Haiku. (Including my personal favorite BeShare)
can it at least make it to Package Manager? With a warning perhaps…
I’d say stabilize what you can and release this thing!
As far as 32bit support on 64bit… it probably won’t make it so how about we float this idea, release Beta2 as soon as that feature stabilizes. And another Beta every time a Major feature is stabilized perhaps lumping a few together if it makes sense. These could even just be cherry picked nightlies if it came right down to it.
That is not how the project sees the beta phase. “Beta” means feature completel, bug fixes only. At least for such a massive change as 32bit on 64bit compatibility. If it were a simple feature added to some app, it may receive an exemption, but not something this big appearing that late in the game.
Maybe we’ll see the feature in the first R2 nightlies in a year or three…
There does not seem to be a single vision on this. I don’t have a problem adding more features to the betas, as long as we make sure there are no regressions. This means the feature should spend some time in the nightly branch and go through careful testing before it gets to the beta branch.
KapiX efforts on fixing the unit tests are a welcome help for this, as they will help detecting regressions.
Are you talking in general, or is there booting problems with Haswell+? A quick search in trac shows nothing, but maybe my keywords aren’t the best.
If there are, a quick re-test would be nice, and you can already do it with the current nightly.
If there is no booting problems with Haswell, then please, try to format your words so that it won’t generate misunderstanding. The hype already started at big news sites (osnews and so on) and it could happen a new user checks the Haiku forum, sees your comment and says: “Oh, my chipset not supported then, whatever.” That would be not the best marketing.
And if you have problems, make bugreports and attach syslogs. “Hopefully it will boot” is not of any help, as no amount of fingercrossing will fix the possible problems .
I can see where that could make sense in a larger project with tons of developers, but that doesn’t seem to be a good fit for Haiku… and is probably a large part of why there is so much time between releases, it probably isn’t a good policy moving forward if you want the project to actually move forward.
If you completely freeze beta… you can guarantee that it will just sit there and stagnate and nobody will use it after a year has pass just like the alpha releases. Currently everyone lives on nightlies… for Beta as long as a change doesn’t break things I don’t see why it shouldn’t go in. Major features should and must still be going in… but not changes to existing APIs etc…Beta honestly should be a subtle but significant change rather than earth shattering. Pushing off major features will deflect both developers and users. The utility of a formal release is seriously questionable because of all this. If Haiku anounced it was never doing formal releases again and would just cherrypick nightlies as stable into a stabilization branch… would anyone bat an eye?
Adding more unit and integration tests is probably a valid thing to do to ensure that breakages aren’t happening rather than just outright freezing things. As that is how many other projects deal with this without paralyzing the project, Mesa3d is a good example, ReactOS and Wine do a ton of unit/integration testing.
Also bearing in mind most of the problems people are going to have with Haiku are not with respect to the stability of the software itself, but with support for their hardware.
I have reported what I can. Nothing happens when I select the USB stick, the PC just instantly reboots. Tried with two different USB sticks. Holding down Shift does nothing. Haiku is also the only OS that doesn’t work from my testing.
Not sure to what exactly you’re referring, but the alpha releases did not impose a feature freeze. So that couldn’t possibly have affected the release schedule.
Nobody said anything about “completely freezing” beta. Bugs will still be squashed and things get polished. With the package managing in place releasing regular updates to the Beta will be rather easy.
On the other hand, if we continue to add feature after feature, that is a sure way to rather increase the bugs count and makes sure we never reach R2. (Edit: R1, of course)
In the end it’s the judgement of the release coordinators. They’ll be praised for added bugfree features and will suffer the blame when something goes wrong.
Let’s get this R1 thing over with and let the adventurous among us enjoy R2 nightlies/alphas/betas for the years to come.
We did not agree with waddlesplash on this, so we settled on a compromise:
We create a branch for beta1
Development continues as usual in trunk
After the beta1 release, I will keep cherry-picking bugfixes and well-tested features into the beta1 branch
We can later see wether it makes sense to release beta2 from trunk, or from the beta branch with extra bugfixes
This means we have a “stable” channel starting from beta1, and we’ll see if it’s worth the effort or not. alpha and beta releases are also a way to experiment with the release process to see what works and what doesn’t.
In my view, if the plan is to just “code drop” the beta and then go on as usual with making changes to the trunk, we may have new bugs getting there and then it could take years before we have something stable enough to be a beta release again. Of course people will then be using the nightlies, and complain about how things keep getting broken, how software used to work but doesn’t anymore, how an old video driver worked on their hardware, but the new version doesn’t, etc.
I find this unacceptable, so I would prefer to provide a more stable version of Haiku. It may also help us compare two “live” codebases especially when debugging driver problems. I don’t have a problem with adding new features, I just want to make sure they don’t do more harm than good. And when people really want something from the nightly, it means it’s time to integrate it in the release channel, or maybe start thinking about R2.
Awesome!
.