Do betas really matter? The nightly builds seem to work well enough. I suppose it’s good for ‘marketing’ to trumpet a new beta or version, but if someone were hanging on to Beta 1 and waiting for Beta 2, I’d suggest going to the nightly builds rather than waiting.
Haiku has come in for a lot of criticism for the long gap between Alpha and Beta. It is now over a year since the first Beta emerged. I should be inclined to find a recent nightly that works well, add all the normal packages, and call it Beta 1A so that people don’t waste their time downloading the present Beta.
If Beta 2 isn’t ready in six months time, do the same again and call it Beta 1B
1 Like
You’re correct. Last year for R1 Beta 1 I attempted to commit us to a yearly release cycle in the Fall to try and encourage us to get in a “release often” mind-set.
I’ve been raising branching R1 Beta 2 for most of this year now but can’t get the support/velocity with our developers.
- [haiku-development] Reminder: R1/Beta2 - Work begins end of Aug. - haiku-development - FreeLists
- [haiku-development] [RFC] Haiku R1/Beta2 branch? - haiku-development - FreeLists
There are some definite issues, but I don’t feel like they’re clearly defined/categorized anywhere. Given the democratic nature of Haiku and it’s releases… I really can’t just “do it” without some support of the contributors.
Not to be pessimistic, but this is how another release date slides into infinity. I want us to do better… but I can’t make it happen alone.
On a more positive note, here are some ways you can help get R1 Beta 2 out.
- Become a contributor and help squash bugs.
- Become a tester. Help refine bug tickets in Trac.
- Become a community activist. Interact on the mailing lists and add to the discussion.
6 Likes
Then let’s make a list, I don’t know, using the bugtracker?
If people can’t be bothered to add their blocker issues there, then surely they really aren’t blockers.
One you’re in charge of is #15474, and I think we’re on a good way for that one.
#14805 is essentially a recompile of wpa_supplicant and a refresh of our base repos.
#15000 (USB3 boot failures) is annoying, but I would not consider it a blocker, we can fix that later if it’s not ready in time.
And that leaves us with #15145, which has a workaround in place for now, so I don’t think it’s actually critical
Things that people have complained should be in the list, but have not actually created tickets for:
- HaikuDepot problems: empty list of packets on first start, etc. Sounds ok, it’s only a beta after all.
- Updating WebPositive: keeping me busy right now, but can be done post-release anyway, don’t wait on me.
So, let’s rebuild wpa_supplicant as instructed in that ticket and get rolling?
It will not work by just sending emails to the mailing list, but by having tickets and tracking progress, I think it’s possible. And we don’t really need the whole team in, if they failed to create the needed tickets, it’s too late now. It’s not like they have had a whole year since the last release to do so, right?
WRT HaikuDepot tickets, these two deal with not (completely) populating the package list:
- #14927 - HaikuDepot doesn’t show any packages
- #14840 - HaikuDepot doesn’t autorefresh repos on first Launch
This one also feels rather important to fix:
None of the tickets are yet in the beta2 milestone or have a higher priority.
wanna help out? I see you’re an admin in trac 
I trust the release manager(s) will make the right decisions.
Wanna be a release manager?
Hell, no! And not only because I’d be completely unqualified…
What makes any of us qualified? Release Managers only need to be able to type on a computer, and tell people not to merge stuff
Let’s make it a GCI task then! 
3 Likes