On Tue, Nov 04, 2014 at 03:53:40AM -0800, Niels Sascha Reedijk wrote: > Hi, > > On general I agree with the statements in the discussion. In this email I > argue that we might have to tweak our view on our target audience, and at the > bottom I will outline my view on the future release discussion. Hi, It seems your email client does not properly quote what you reply to (at least in the text version of what it sends). Could you see if it's possible to fix this, as it makes your posts hard to read for me? > > I don't think the crazy "release every 6 months" schedule of Ubuntu is a > > good solution at all. And, they have LTS versions, too - which is the > > only thing I would look at if I wanted a (somewhat) stable system. The > > amount of updates and fixes you get daily on an LTS install years after > > the release is a bit frightening, too. > > As I said, I'm a fan of rolling releases. And I do count Haiku into > that, too. But that doesn't mean that components may need time (even a > lot of time) to evolve until they are ready for the inclusion in a > release. One thing at a time. > > I agree with the concept of doing releases more often. There is a hidden > cost, in that major updates do tend to introduce new problems and issues that > you generally want to fix in a QA-process. Just how hard that is, is > demonstrated by Apple, in which the annual release schedule does seem to > increase the amount of problems in their OS’es. Major updates don't introduce the issues, they just make them available all at once to the general public. With a rolling release and no LTS, you get the same amount of issues, but spread over time. As a result, there is never a stable system to run, and new issues appear as older ones get fixed. I like the idea of major releases, because at least you can know what works and what doesn't on a given release. With rolling updates you're never sure. In other words, rolling release does not mean "permanently up to date and with full stability". It's a tradeoff. This can be limited by having a QA process before things land into the rolling release. I can see an advantage to rolling releases, it's that when the issue gets fixed, the fix propagates faster to the users (they don't have to wait for a new release). > I would like to add that IMHO the OS-wars are over and dealt with. With it > went the market for alternative OS’es. Mobile is the new hot thing, and even > there we see that the market is about to be settled. There is a choice of two > OS’es, and I have the gut feeling that the desire to install custom roms or > to jailbreak is decreasing there as well. So I think the tinkerers have moved > on to the computers they are carrying with them all the time. The market for alternative systems was never all that huge. Things are settled on that side since the early 90s. I think there is room, however, for a "traditional" desktop OS. With Windows 8 trying to be more touchscreen-oriented, and the same is true for GNOME 3 (not sure about how things are on the OS X side). I think at least part of our user community (including myself) is people wanting the good old keyboard and mouse desktop experience. There is a rather big number of Linux desktop environments and distributions targetting that same audience, and I think there is space for us there, especially as we're still ahead of some of those Linux based projects on some points. > I am cautious about making time-based rolling releases, I think I would > prefer the releases to be based around one or a few major features. In the > tailwater of those major features the smaller updates to applications can > follow. There is a problem with that, with all (or most) developers working on Haiku on their free time, it's easy to come up with a feature list for each release and a roadmap, but then comes the time of people having to actually complete the feature. There is no way to put strong management into a team of people working on Haiku as a hobby - as soon as it starts looking like work they will lose interest. And we don't have enough money to hire people at a price high enough that they would accept it as a job, either. Time-based releases are a way to keep people motivated. You want your preferred feature in the next release? Just getthe code production-ready and it will be merged. If you miss the window, you may have to wait for 6 month or 1 year before there is another opportunity. -- Adrien.