@Karl-Han Re your development question:
Yes me too. Although of late I’ve had to concentrate on offering better support for our Stable channel subscribers via a planned appliance id management tool. This is by way of a value add to those how are currently helping to keeping afloat our current development path.
This is theoretically possible but is likely very non trivial, especially if you intend to maintain CentOS compatibility, at least for the time being, and current (to-be) openSUSE Leap 15.1 and openSUSE Tumbleweed compatibility also. This is also in the light of our need (this year) to update to Python 3 and then transition to a newer Django; both in themselves non trivial projects. Any pull requests that have not been tested on these last 3 platforms, and the last 2 in the near future, will not be merged. It’s a surprisingly massive task to transition a project of Rockstor’s size but it will hopefully get easier as we go on. I found many CentOS’isms in my current efforts towards the two stated openSUSE distros; detailed in part in:
And the various distros tend to go their own way in how they construct their btrfs offerings. OpenSUSE is, from what I can tell, the only distro that has a default btrfs install and thus has the larges investment in keeping their btrfs eggs in a row. And their sponsors SUSE employ quite a few of the btrfs developers. With SUSE offering enterprise linux support and openSUSE to SLES now assuming the same relationship re binary compatibility / transfer relationship as is the case with CentOS / RHEL, except as I see it openSUSE has more independence: openSUSE is our natural home: and the only distro to back btrfs by default as apposed to RHEL’s previously employing a single btrfs person and then dropping even preliminary support for it in their offerings. Also I see Tumbleweed as a very Arch like distro at least from the community driven, cutting edge point of view; except that their is a possibility to transition to something more stable that also has the SLES angle mentioned above. So given that I cannot help with any Arch development myself however the relevant docs for Rockstor development, should you wish to have a go, are:
Contributing to Rockstor - Overview
and more specifically it’s following section:
Developers
And our developer doc re the current team effort to move to openSUSE is:
also note recent user reports on difficulties on compiling against Tumbleweed that I have as yet not managed to reproduce (at least the later elements of @jcdick1 ongoing report anyway). Their earlier reports re compiling difficulties managed to uncover an upstream issue re Tumbleweeds alternatives implementation breaking with regard to expected ‘in path’ links to the postgresql db server offerings:
But know that we have already had another significant breakage in our Leap 15.0 docker compatibility and our current 3 platforms all treat docker differently so even in just that element there are non trivial challenges in our code having to adapt differently in all those cases. I expect Arch will have yet one more ‘take’ on how docker should be handled. We also have the challenge of differing package availability so it’s really quite involved when it comes to it. But with enough informed contributions I don’t see why, in time, Rockstor couldn’t at least work ‘unofficially’ on a number of platforms if the will is their to at least try. I’m afraid though that I don’t have the time required to review anything submitted in the name of Arch. But luckily I’m not the only reviewer so their is hope in the ‘other’ distro support. But my focus is on the openSUSE offering while maintaining CentOS compatibility in the short term.
So in summary I would advise that you first try building from source on our current released platform CentOS and then if interested in contributing code to also familiarise yourself with building on Tumbleweed and Leap 15.1. You may find that our currently progressing Tumbleweed offering fits your requirements for super modern software combined with Rockstor’s user friendly way. Also note that when compiling the code yourself you get the latest code offerings, ie akin to our stable channel subscribers currently: the hope here being that if your are compiling yourself you are also more likely to contribute back to the project in code contributions while our stable channel subscribers assist with Rockstor’s sustainability financially. Due to mainly human resource limitations we have had to drop rpm releases in the testing channel, at least for the time being. See the following thread’s intro section for the background on this move:
Hope that helps. I for one consider Rockstor on an appliance basis and not just a package one installs. Although at it’s heart that is how Rockstor is updated, but that package in turn manages a number of other services, ie docker, making the porting of it a little more tricky due to quite a few inter dependencies.