R1/beta1 release plans - at last | Haiku Project


#1

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.


This is a companion discussion topic for the original entry at https://www.haiku-os.org/blog/waddlesplash/2018-08-19_r1beta1_release_plans_-_at_last/

#2

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.


#3

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. :smiley: Awesome!


#4

i’m very happy that R1/Beta is soon to be release… thank for All Haiku Dev…
thumb up… :+1::+1:

i will do my part my best as translator… :sunglasses:


#5

Hooray! The Beta is coming! :smile:


#6

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…?

The release notes will have them, for sure.


#7

What can we non-dev’s do to help?


#8

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…


#9

Are we going to be able to install it on a Macbook?


#10

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.


#11

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… :slight_smile:


#12

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.


#13

Amazing. Hopefully it will boot on hardware newer than Haswell.


#14

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.


#15

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 :slight_smile: .


#16

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.


#17

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.


#18

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. :slight_smile:


#19

What can we non-dev’s do to help?

Testing the RC, which will be relased on saturday and publish the bugs you found, so that the release in september will best as possible.


#20

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.