That to me sounds like shifting the problem to a different place.
What happens when people see that release after release nothing changes? Next release they are going to think “Why bother? Probably nothing has changed at all anyway.” Would they try Haiku again? I doubt it.
Now at least a release is an event.
We should find another way to do that because we don’t need to establish a view that Haiku is broken and nothing ever gets fixed.
I see where you’re coming from, but there is another side to what you’re proposing, and I think it’s better to keep doing things the way we’ve been doing them, at least until circumstances change. Fixed release schedule would work if we had full-time developers working on things, but we don’t.
I wonder if visual changes would help then? At least with macOS, there’s been this idea since Leopard (Jaguar, Panther, Tiger were all major releases)…
To visually explain this:
10.5 Leopard was feature focused
10.6 Snow Leopard was fixes/improvements
10.7 Lion was feature focused
10.8 Mountain Lion was fixes/improvements
(10.9 Mavericks kinda broke this cycle as the second Snow Leopard)
10.10 Yosemite was feature focused
10.11 El Capitan was fixes/improvements
10.12 Sierra was feature focused
10.13 High Sierra was fixes/improvements
10.14 Mojave was feature focused
10.15 Catalina was a stopgap release to 11 really, but improved Mojave
11.0 Big Sur feature focused, the next big release of macOS
11.1 (if I had to bet, this will be improvements and system level changes to Big Sur)
So to avoid feature fatigue or whatever (6 month releases would all look and feel the same), why not have Haiku follow the same pattern so users feel they’re getting something out of the releases? Like the next release could just be improvements to Beta2, Beta4 or R1 could be a feature release with new wallpaper, icons, features and whatever
I think the point is that we want people to try Haiku. We need to get them to place a foot in the door. If they do that, and like what they see, then there is a good chance that some of them at least will stick around, even if progress is slow. And if we get a few people like that, and they start to contribute, progress will be faster.
At the moment, we aren’t getting enough people to try Haiku.
A Media Alert is a small press release with the “Who, what, where, when, why” in a separate section and a single paragraph with the how and contact info at the bottom. It would be perfect for this. If we decide to publicize this opening, I can put together one and send it out to tech media contacts. Then hopefully they’d run with articles about “Haiku looking for full-time developer.”
Zig looks interesting. I may have to try it sometime.
To refresh my memory in C++ programming, I started writing YAB2Cpp as a transpiler from a certain BASIC version to C++. I haven’t been working on it much lately but prior to starting my current contract position, I was pretty active with it. It’s written in C++11 just for grins because my last C++ code was more than 10 years ago. Maybe we could team up in our spare time if bringing computer languages to Haiku appeals to you.
Maybe once my current contract expires I can contract for Haiku Inc. I’m trying to learn system administration at entry-level wages but my employer has little time to train me in. I currently earn $15 an hour but am only getting in minimal hours at this time (6 hours in the past two weeks). Name your terms.
Sorry for digressing on threads’ topic a bit, but I am really happy to see people mention their interest in Zig here - this is definitely something I am interested in as well and I even opened a ticket on Zig’s issue tracker for this purpose, but have seen someone else working on the port already. IMHO, Zig is something the industry has long waited for, as a real modern replacement for C, and it feels much more sane than Rust in this regard (which tries to be too clever and is way too complex for its own good). On a side note, I am also planning to work on Julia port, right after I finish my first port on Retro (thanks @korli and @Begasus for all the code reviews and guidance!)
As for the question at hand, of finding new devs - does Haiku Inc. use LinkedIn for any visibility purposes? I’ve seen its profile there and followed it already - I think there might be many people willing to help spread the word if anything.
And additional observation - I would say that the project could benefit from some Project and QA management effort as well - there are issues in Trac that are kinda more than 10 years old and probably could be re-tested (if possible and not hardware-dependent) and groomed a bit at this point. Pruning and closing older issues that have not been reported or actioned upon or even confirmed for a long time - would help progress visibility and dev focus, IMO. I can volunteer to help in this regard.
We are in beta phase. We are fixing bugs and not doing new features at the moment. Not in the planned roadmap at least (people will hack on whatever they want).
More generally, there will not be any “master plan” unless someone is paid. If you pay someone you can tell them what to do. If you don’t, they are welcome to contribute on whatever they think is interesting/useful/fun. And so things will happen when they happen.
Sounds like a new coat of paint trying to sell an old car with a leaky and broken engine. Please don’t do that. Haiku has a strong identity related to its icons and general look and we are not changing it just because “look we did something!”. Also, it take years to refine a theme like this. And it also involves a completely different set of people (we’d need graphic designers, not developers). Changing the style also annoys app developers because they now all need to redo their icons to be in the current fashion.
The look is one part of Haiku that is mostly done and do not need extra work until R1. Why throw the good parts away? We should instead work on what’s not finished yet
Only under the condition that we are really sure the problem is fixed.
“We did not do anything for 10 years” is not a reason to close an issue. It is super annoying when I report something to other projects and they do that: no action, and then someone says “no activity here, closing the issue”.
I think pretty much all of these old issues are still valid and need work. We do have a QA team and they actually already do a reasonably good job at this. But they can also do with more help, sure
Just to be clear, this goes without saying - if there is actually a problem still, it needs to be addressed. What I meant here, is potentially some issues that were either never confirmed or misinterpreted or not relevant anymore, and yet without any follow-ups on status check. So obviously, there would be needed some going over these issues and smoke-testing them again, to see if they are still valid.
I agree. The promotion of Haiku can go a long way to just keep the buzz going between releases. The developers have more than enough on the plate than to release just to release. Short vids to showcase capabilities, blog posts to bring attention to breakthroughs (the recent activity on RISC-V, ARM etc., the Medo app, programming languages support, gaming efforts) can generate interest and attract more support.
Sorry… I do know Haiku’s dev team does a heck of a lot and often gets little thanks for it and demands for more features — and tbh I realize I did that here too, guess I’m just trying to give ideas for the future of Haiku (but you’re totally right, it’s up to the dev team building Haiku not users to choose when and what to release)
The easy solution here is if you want more often releases of Haiku, step up and help out
We’re not turning away developers or anything as long as you follow our style guidelines and submit reasonable patches.
Thanks for the invite, problem is my skills stop at apps pretty much, but there’s a few ways besides the hardware list that I’m thinking of where I can do some stuff
@leavengood So is Haiku Inc. going to announce the application for the engineering position officially via the website? The potential candidates are still waiting for any action from the organization.
Another reason to release R1 as soon as possible: Making frequent beta releases without notable changes would look lame and pointless, but everyone would welcome bug fix releases each month once a release is out. A beta is supposed to be out once there is stuff to test.
I am not happy having to use debug releases with lots of checks enabled, I’d rather use a proper release that gets frequent bug fix point releases.
I need to write up the “job posting” and run it by other Haiku, Inc people and some of the current core developers. I had family visiting these last few days so I did not have time to do this yet. I have some other Haiku, Inc obligations to do as well but I can prioritize this.
