Actually, you don’t see a big difference because one, devs are overly cautious. They know that a lot are using nightlies and they fear the flames on forum a bit. IMHO, they shouldn’t and there should be more experimental things on nightlies. Two, even if you’re using nightly, you’re using the same software from Haikuports that are for most stable versions built against the beta.
What could be added is a ‘testing’ repo on Haikuports allowing i.e. software without translations yet, ports that are building but still need testing, etc… The problem is always the same; it’s a question of resources, money for infrastructures, people to do the job… Also, if you put something like that in motion, it has to stay. There’s no going back and you have to think twice.
Well, as someone who runs nightly only and involved in releasing beta2, beta3 and beta4 maybe i’m just not smart enough to see it.
When nightlies are stable depends a lot on the time, most breaking changes are done immidiently after the beat or in the middle of the cycle. To the end of the cycle things stabilize, and that is also the time people begin crying about how they are currently running nightlies and don’t see the issue.
If we abandon betas we loose our ability to properly integrate and test changes, and we loose the ability to produce an actually stable system. Terrible idea in my opinion. But maybe you know more.
@Androsio We already have sources for the ports, you can just clone them from github and build them if you are so enclined. What we don’t have is any options for ports, Haiku is pretty opinionated and we try to do things only one way.
Testing and current ports currently makes little sense as we don’t maintain the vast majority of ports, only port them, and of those we port we port the stable version.
Native software has proper development/testing snapshots if needed. But those are on their own release cycle obviously and don’t need to be distributed through haikuports.
As I understand it, the problem is with the plurality of betas. Beta software, as far as I understand, should only be for testing, not for release and use as working system. With a small group of Haiku developers working on a volunteer basis, those betas quickly become obsolete (due to the long development time and the emergence of new hardware, new standards and new needs in the field). And you again and again need to release a new “beta”, which is not a final or stable product in any way.
I think the team’s goal should be to focus on realising Haiku R1 and not on the interim beta releases (“beta 5 release”, which is getting a bit comical to be honest).
What do you think a beta release is?
Edit:
To elaborate on this, a beta release in the classical software model does not mean “This is a release, but is a beta” but rather “This is a beta for the next release”
It is a crucial part of the actual release process towards R1. Sure, we could say “fuck it, who needs betas”. And the effect will be the same that it was between the last alpha and first beta, no useable releases. Nothing you could actually as a user confidently install without getting into the development.
This will just lead to there beeing no more stability at all in the nightly branches because the whole “let’s slow down, clean this up, fix some bugs and make it useable” cycle wouldn’t exist.
What is beta for the Haiku development team?..
“Look, world, we’ve created Haiku, which isn’t finished yet and isn’t suitable for practically any business, but you can try it, and if you want, you can contribute to the development of this promising system.”
And the Haiku team did it, the world learned about Haiku.
Now is the time to show the world that the team can make the final product.
So now it’s time to announce to the world that Haiku R1 is coming soon and focus on that. Enough with those betas. If you want, let it be one beta sprint for R1.
I have no interest to try and deploy R1 now, this will take years between which we have no useable versions. What’s the point?
There are still massive issues plaquing haiku before we can even think of R1, on the top of my head: No DNS-SD discovery of services (mainly printers), No Webkit2, no api to embed HTML content (e.g Mail application suffers through this)
According to the bug tracker there are almost a thousand open tickets against R1, and that is with having moved many to R1.1 or R2. It’s simply unrealistic to expect R1 to come next week.
https://dev.haiku-os.org/query?milestone=^R1&status=assigned&status=in-progress&status=new&status=reopened&order=priority&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=milestone
Sure, Haiku has come a long way. And we have compfortably useable betas now, but don’t pretend this is in any way production ready, that is just disingenious to users wanting to try it.
Personally I think these constant threads asking for “let’s just release R1 now” are ridicilous, this has been discussed countless times and the only argument for it seems to be “I dont like betas” or “we (exclusing the poster) should focus on R1 because i say so”
If you want Haiku to reach R1 quicker then contribute to areas you deem important to reach it, trying to convince the devs on the forum to release a version as R1 despite not thinking it is ready makes no sense.
The point is to optimize activities and reach the goal faster and more efficiently. This requires looking at what is hindering this goal and what is helping.
Don’t take it personally. Look at it matter-of-factly.
Yes, clearly stabilizing the system and fixing bugs is hindering progress towards R1 … /s
The matter-of-factly is that Haiku is a volunteer project, and I get to work on whatever I want. Today that is haikuwebkit, for me. The other developers do the same, and nobody has any interest to drop the betas.
So why keep discussing it?
I have the same right to express my opinion as you do? or not? Why do you think you have the right to unilaterally end discussions? If you are not interested, just don’t participate, as you said yourself, Haiku is a volunteer project and everyone does what they like.
I personally like, among other things, technical ergonomics and technical design, action and work efficiency, cultural and technical progress in general.
That’s why I’m interested in Haiku, because I see it as something progressive in the field of operating systems. Am I deluded? Many things seem like they could be done better, but as we mentioned, everyone here does what they want… it’s not bad in itself, but is it enough to achieve the goal?
I don’t see how you go from a simple question from my side to immediately feeling attacked, on freedom of speech grounds of all things.
Maybe this is a sensitive area for me… Nevertheless, geography and geopolitics play a role. Like it or not, we are all a bit stressed in Eastern Europe. Don’t take offense or take it personally. Have a good day.
That is exactly what we do before shipping a beta.
So, you are not asking for less releases. You are asking for us to do a release every month. That is not less work for the deveiopers, that is more work for the developers.
You are wrong. We get debug reports from users that are on the beta and do real work wirth their computers.
They are beta quality, which is not at all the same as nightly builds. Nightly builds are completely untested and may be completely broken. Betas are similar to release candidates, there should be little to no surprises on these. And usually we manage that. People running the beta will not have regressions on their system, it will be stable and not crash.
This is from the Haiku side. Haikuports currently has no equivalent system, and so, all software there is immediately made available for everyone. This is a bit simpler for them, to manage only one “stream” of packages. But it means things coming from Haikuports are constantly moving, and there are regressions (but then these also get fixed quite fast when they are discovered).
We always get conflicting signals. We can’t at the same time be experimenting with things all the time, and trying to stabilize Haiku and get it out of beta phase. So, yes, since we are in beta, and things are more or less focused (depending on each person’s motivations) on getting a stable non-beta release out, there are little experiments going on. Maybe when R1 is out we can start doing a lot of crazy things (although I think I would rather happily use R1, continue fixing bugs, and work on some other of my projects and not spend my life writing an operating system?)
We can’t get the R1 release right if we don’t train ourselves with the betas. With each release, we discover new challenges and we solve them. And we make the next release better. Our current challenges are setting things up so we can ship betas more often than once a year, and also setting up some things so we don’t fall several major versions behind on our dependencies (ICU, ffmpeg, openssl) and end up shipping unmaintained versions of these with known bugs that won’t be fixed. This largely explains the delay in shipping beta 5. It would equally block us in shipping a final release.
Just a version number. Why do people care so much about how we decide to number our releases? Would it be different if we used latin, hebrew or cyrillic letters instead of greek ones? Would it be different if we used numbers? Would it be different if it was version 0.4.7 or 1.4.7? Or hrev55123+128? Or just a git SHA1?
I don’t think so. The software would be the same.
So, instead of version numbers, let’s talk about features.
There are currrently more than 600 tickets in the roadmap for R1. What is your plan for fixing all these in one sprint? Knowing that we fix about 100 to 200 each year, and that new ones are discovered (or introduced) as well in the process.
Or do you think most of the items in this list are not needed for a stable release? That is indeed a way to make R1 happen faster. Which one of these tickets should we push back to after R1 then?
I think most of these don’t need to be in R1. BeOS didn’t have any of them, and the goal for R1 is mainly to replace BeOS. Then we build from there and make an R1.1 and so on. Yes, it means R1 will be far from perfect, still. But it’s a starting point and then we can move on. We don’t have to immediately start breaking everything and rewrite it all for R2 after R1 is out. The R1.x series will hopefully have a long and succesful life!
I can understand this, but at the same time I’ve never used BeOS, so for me personally my goal is more a “Desktop OS i can recommend to my friends”, and base what I work on more on that. : )
Ah you missed out on something great when BeOS was alive and well in the late 1990s to 2000. The awesome thing is, the Haiku project is replicating the BeOS like experience with modern flair and fixing things that the Be engineers never had time to fix or make better.
Yes, everyone has their own priorities that don’t always match up with the project goals, and that’s great. We can also re-discuss the project goals, but personally I would rather avoid moving the goalpost for R1 any further than we already did. So I’m more open to discuss what to remove from it, and not what to add 
It is possible to minimize Haiku and remove some things from the main system and leave it as 3d party software, demos, optional or something similar. The following excluded applications can be developed separately from Haiku itself:
autoraise
charactermap
clock
codycam
cortex
diskusage
fontdemo
glteapot
gradients
haiku3d
icon-o-matic
launchbox
magnify
mail
mandelbrot
mediaconverter
midiplayer
musiccollection
overlayimage
pairs
patchbay
pe
people
poorman
processcontroller
pulse
remotedesktop
resedit
serialconnect
soundrecorder
sudoku
switcher
text_search
tv
webpositive
Also, there are probably libraries that can be added as extras.
All these things can be freely developed separately of Haiku development.
In the user manual (in StyleEdit text), additional more frequently needed programs (and their alternatives) could be offered, which the user could download separately by himself.
Point is, that is your personal list. Other people lists may differ. And then we end up wasting too much time discussing on what to remove, or defending/accusing this or that piece of software.
Or we can remove everything, and tell people “we don’t provide a complete operating system, just a kernel, and you have to figure it out yourself”. And then people will start making distributions with their own choice of software, and it will be the same complicated world that Linux has right now.
If that’s where we’re going, let’s save a lot of time and effort by just all switching to Linux.
At this point, what else is left besides preferences? HaikuDepot?
Even as somebody who wants the project to consider a minimal ISO which allows for manually picking additional packages during installation, that’s just alongside the regular ISO as another option. It should be evidently clear that Haiku’s focus of being a desktop OS is going to mean a bunch of apps developed and shipped alongside the core system.
I am on Linux.
…Haiku doesn’t have to be a Haiku distro also.