@jfearon A very belated welcome to the Rockstor community.
I’ll try and chip in again on this one, communication wise. But this is my personal view as a major contributor.
The story so far on testing channel is unchanged, ie there have been no more rpm releases since 3.9.1-16. Leaving the convenience of rpm updates as a ‘value add’ to stable channel subscribers only for quite some time. But also note that this pertains to the rockstor code only:
Not entirely what we had planned (by now), but it currently fits with the available resources. More and more open source projects are having to consider their sustainable stance and this is an element of ours; currently at least. I personally see us moving more towards a model such as is instantiated by Bareos where they occasionally release a free as in beer rpm but serve many more frequent rpm updates to their subscribers: but are still free as in libre software, ie they also have their code on GitHub. This is essentially what we are in practice currently (doc updates re channels definition needed). With patience all get rockstor code updates in time as the ‘free beer’ releases do come in time, but there is a definite ‘value add’ for subscribing: ie more frequent and more convenient updates.
But all our code and development is in the open and so building from the source code, and updating your kernel, as indicated in a prior post of mine here:
and confirmed by @kupan787 there after:
is available.
And the build process is, and has been for a few years, well documented. It was one of the main elements that attracted me as a developer / contributor. This is not always the case with open source projects. But of course, like in all other areas, there are always improvements to be made.
Essentially Rockstor and it’s sustainability is a work in progress and we have to use our time and effort to best affect. I have been putting my time into trying to make disk / pool / share management more robust / capable and have also dabbled in the docs, and the forum of course. And given there is already documentation sufficient to enable any one to build and run the very latest version that day (accepting a wipe of their database) along with whatever elrepo kernel-ml they choose, I think it’s best if I at least continue to focus on those issue that I indicate on GitHub as my current focus, often along with justification for the chosen order. I am also in the process (as evident in my more recent pr’s) of improving portability so that we might ‘stand on the shoulders of a different giant’ so to speak: which in turn frees us from for example kernel and btrfs-progs details. But all this takes time and if I for example spend that time instead on what was the prior testing channel we may well end up, as we seemed to be heading towards before, with an imbalance of support and contribution.
Please see these statement in the context of our previous failure to live up to our hope of working both channels successfully. Where our divided efforts lead to stable channel subscribers discontent with update frequency. Out of necessity (and sparsity of ‘value add’ options in a fully open source project) we have now reversed that situation. This has in effect been a win win situation overall (Rockstor still exists) but does not and has never precluded those who are willing to go through a little inconvenience (git build db loss etc) in order to avail themselves of what the latest code has to offer. Also note that the build process is a minimum capability to contribute code wise and so serves as an empowerment to those who wish to be able to control / observer their own data management systems in that way. And those same individuals can in turn then contribute on that level. Regular users can in turn help to sustain the project via the ‘value add’ of convenience offered by the stable channel (rpm) updates. Without the stable channel subscriptions Rockstor may well already have disappeared or simply become unmaintained. That is by definition a loose loose as all those that work on Rockstor, as far as I’m aware, currently at lease, enjoy it. And the stable channel subscribers are now more frequently served their ‘value add’.
It is as well to remember that most open source projects are sustained on passion, but most also require funding to achieve a satisfactory level of polish, and or independence. See gnome / kde / kernel etc. I for one would like to see Rockstor prosper and simply having more users is not the answer. We need to continue to build a contributing community which is why I am taking the time to express my view on the matter here, and why I accepted the forum admin role as well. The world is now dominated by free as in beer software, on the server side, but there is almost always a backer or a ‘value add’ that helps that situation be sustainable.
All those frustrated with the lack of ‘free beer’ testing channel updates please consider attempting a build, it’s really not that difficult. Just remember that your db will be wiped and rock-ons, as per config backup and restore, are problematic so best uninstall all rock-ons (and wipe rock-ons root) and start a fresh with the new version. Also remember to uninstall your rpm rockstor package instance. If this is not to your liking then please consider alternatives such as FreeNAS (open core - given TrueNAS), Lime technologies unRAID (30 day free trial with drive count limitation per pay level there after - also only open core), or openmediavault (same originator as FreeNAS I think - opensource over the wall type with CLA). Or start a new thread on how you think we could best serve the casual user who does not intend to contribute, on a code / docs / forum level, in a way that will require no additional support. Or consider subscribing to the stable channel and encouraging others similarly if that fits their use case also. All of the indicated alternatives projects are, by many accounts, doing good work so please consider supporting them if they serve your requirements better. My personal choice is to try and support Rockstor as I like it’s simple yet capable mix, which is in a large part down to the focus on using btrfs: which I consider to be the future of file systems in this area.
Also note that pull requests are welcome, especially if they scratch an itch, as others are likely to have that same itch. And if the current ‘nuke and page’ build process leads to fresh itches then ultimately everybody will win with that particular itch satiated. We are after all not all that dissimilar. But with all the combined efforts to date we have a surprising lack of options on the fully open source NAS front. But note that no one is ‘stuck’ with Rockstor: it is a conscious choice. The part one plays in this choice is very flexible.
Hope that helps and doesn’t come across as too preachy. I will continue, for the time being, to do what I can to assist all those on the forum with heir issues as my time permits. As always we are all after a win win situation here so please keep in mind that a mutually beneficial outcome is best. This is a team effort that involves the users as an active component (mostly via this forum).
I’ll end with a graphical “Rockstor Git Gource visualisation” up to around 9 month ago:
A graphic that I created at the time to help visualise how much of a team effort the rockstor system, rockons and docs included, is. You may also be interested in how this graphic was created, and for that I created a blog post entitled: “Rockstor Git Gource – project visualization”, subtitled “Gource is Git shiny.”
http://rockstor.com/blog/btrfs-nas/rockstor-git-gource-visualization/