Hi,
I'm happy to announce a new version of rpm-ostree - v2014.5:
With this new release, there is now a new overarching name/brand for the project formerly known as "rpm-ostree":
Fedora Atomic Initiative
------------------------
The new website replaces the old one:
The website is hopefully more informative now. rpm-ostree was previously mentioned here:
Which got some LWN coverage here:
I also gave a talk at Devconf.cz, which is recorded (albeit truncated) here:
Changes
-------
Since the last release, SELinux now works in fully enforcing mode. This is built on top of new SELinux support in the new core OSTree v2014.2 release:
The rpm-ostree-autobuilder component now generates data sufficient to present a UI of the generated trees, with *automatically* generated screenshots:
(Yes, it's a "build" system that takes screenshots, because it's also a *testing* system - I believe the two should come tightly coupled).
There is now the concept of a "treefile", which is kind of like a kickstart, except without the partition provisioning and ability to execute arbitrary code:
What's next
-----------
The rationale behind the broader branding of the Fedora Atomic Initiative is that rpm-ostree is not an island - the long term vision has a potentially deep impact on the Fedora project technology, structure, and culture. You can see some of the requisite technological changes here:
An example of a potential cultural shift is:
In general, I hope for more people in the project to *additionally* see software as trees, not just packages.
Imagine for example of applying the "branch+merge" concept to entire collections of packages. Say for example that we were doing another technology change on the magnitude of systemd. I'd like to make it easy to create a fork of the OS, with patches to *multiple* packages, test those changes as a unit, and merge them as a unit back into the mainline.
In the short term though, the goals are:
1) Test rawhide (the RPMs)
2) Improve the rpm-ostree/OSTree code
For 1), I think I can demonstrate some powerful value as far as testing goes. Enough that I believe it will offset the costs of having Anaconda support, for example.
To recap again, the TODO list is:
Some of those, such as the /var have active ongoing discussion. Others like /usr/lib/passwd don't - and I would very much like to have /usr/lib/passwd just be the Fedora default. So for that, I'll post a new thread at some point soon.
That's all - there's no separate mailing list for this initiative yet - so please just reuse this fedora-devel-list!
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
