Indeed , as I thought I had made clear in the original post the idea would never to have any preinstalled hidden command calling home, violating privacy and associated laws.
It would be just to have a “BootStats” app on Haiku Depot that devs could intentionally download and that would have a visual notification on boot that the successful boot was logged. Once per hrev. The app could even ask each time hrev changes but as I user I would definitely check the option to post anonymous stats.
Server would be something quite minimalist. A small DB with random, keys, versions and dates. Anyway this will make sense if I actually write the app, post the code for client/server on GitHub and spin up a small instance for it. I just wanted to know if others would find this useful.
As others suggested rather than full releases — which I understand require a lot of testing and time—, it would make sense to have a “recent more or less stable testing build”, which would simply be a link to the latest nightly that seemed stable for a lot of people. I am not even saying it should be shown prominently on the site. Just be an option along with nightlies.
I know personally on one machine I have to chose between using a nightly and working WiFi and using stable and having to use a cable.
I imagine the vast majority of users on Haiku today are either devs or tech-inclined but there’s an intermediate level between fully committed devs keeping an eye on all commits and tinkerers who do understand and accept the risk and don’t use Haiku as their main machine but would appreciate knowing which nightly to try “more or less safely” .
That’s a case where the (third party) app I described above could be useful to share experience easily.
No, because then, you run pkgman update from there, and get the latest nightly that may be broken. If you do anything serious with your computer, you should use the releases. There, we can provide decent support.
The intermediate level you are asking for, where you get the latest new features, but no new bugs, and you can trust your system, does not and cannot exist. You have to make a choice for each of your machines: use the releases, and you can trust your system. Or use the nightlies, and be prepared to hit some bugs and report them (on the forum or bugtracker) from time to time.
This is the cost we ask people who want the very latest features to pay: a bit more effort on their side to give feedback to the developers. We do not want people who don’t want to take part in this (essentailly contributing to the qa/testing of haiku) to be misled into thinking that using nightly builds of any kind will be fine. Yes, anyone you ask on this forum won’t see the problem. That’s because these are precisely the people who are participating here on the forum. If someone wants to make a community run list of “good nightlies”, sure, go ahead. But, the moment it becomes part of Haiku official documentation, other users that are not in touch with us at all will start relying on it. And, no matter how many warnings we’d put on it, they would demand some level of support, that we don’t want to provide. We set up the releases precisely for that: to provide a well tested version of Haiku that doesn’t get broken by accident. Achieving this takes some effort, but the process we use allows to spread that work between the people using the nightly builds, who are also people who know how to report problems and help investigate them. This process has some other costs as well (hosting separate repositories, deciding which bugfixes to port to the beta branch, etc). You cannot replace this by a list of “known good niĝtlies”
What do you think about backporting user-visible improvements to the last beta?
I’ve seen Wifi mentioned here for example,which seems not to work on Beta with some devices but only on Nightly.
A computer without internet is useless to most people,I’d also go for Nightly if that was the case here.
If improvements like this could be made available as update for Beta4,I think many people won’t have a need to use the Nightly anymore.
We do backport improvements to the beta.
That usually however does not include drivers, those tend to require bigger changes and would make it difficult to backport.
You can see for example that some stuff was backported, a sniffer rule for css. Debugging symbols support for the dwarf5 format. Some clipping problems (which fixed a webkit bug) etc.
In generall if a change is small and “just” a fix it can get backported, we likely can do this more than we do now though.
Is that possible to warn peoples about a specific nightliy image
AFTER it turned out :
some critical error may happen if you install this version?
I mean on affecting Nightly install image pages
there is an unused column in the table “Raw image”.
I assume this whole pages created automatically during/after building process of new images - both 32bit and 64bit Haiku.
What if it would be changed to “Installation notes”, and its content would be refreshed from a file.
I assume the image creation happens in directories, so for upload an installation_notes file can be possible if the exact hrevXXXXX is given
for example by authorized people - like devs.
This can contain - in this case -
WARNING :
KDL at boot time
you can boot into Haiku only by
disabling SMP in boot options
HISTORY :
Bug since hrev57761
Ticket : #18915
Fixed in hrev57765
So this way at least for careful nightly users can decide they would hurry to upgrade on every time an upgrade comes … and was not enough curious to read in Gerrit log’s view :
what patches included in this new image file that was made available.
I think nightly also can be used carefully, I mean some using nightly for some unique and numbered improvements / fixesthey do not requires all the fixes / improvementsif their actual system works.
They should read before upgrade : is it worth to me to apply the new patches … or not ?
I know it does not help in case pkgman update blidly executions, but there you can also answer no … after you checked the list of packages would be updated.