Fedora Project Developer Proposes Layered, More Agile Design to Distribution

Karrde712 writes "Fedora Cloud Architect Matthew Miller announced a proposal on a plan to redesign the way that the Fedora Project builds its GNU/Linux distribution. Fedora has often been described as a 'bag of bits,' with thousands of packages and only minimal integration. Miller's proposal for 'Fedora.Next' describes reorganizing the packages and upstream projects that comprise Fedora into a series of 'rings,' each level of which would have its own set of release and packaging requirements. The lowest levels of the distribution may be renamed to 'Fedora Core.' Much discussion is ongoing on the Fedora Devel mailing list. If any Slashdot readers have good advice to add to the discussion, it would be most useful to respond to the ongoing thread there." A full presentation on the plan will be given at the Flock conference next month, and draft slides have been uploaded. A few more details about the discussion are below the fold.

Karrde712 continues, Discussion on the list has questioned whether this is meant to be a return to the old "Fedora Core" and "Fedora Extras" model of Fedora's early life, to which Miller responded: 'I'm aware of this concern — I was there too, you know. As I was talking about the idea with people, it kept being hard to not accidentally say "core". Finally, as I was talking to Seth Vidal, he said, in his characteristic way, "Look, here's the thing. You should just call it Fedora Core. If you don't, people are going to be grumbling in the back corner and saying that it's really Core, and the conversation becomes about a conspiracy about the name. Just call it Fedora Core, and then have the conversation about the important point, which is how it's different."'

Comments

businessmen in software

[Joining Yet Again]

I pretty much left the software development world when all this "Agile" bullshit became popular.

Over the past decade there has been an explosion of methodologies and metrics to coincide with a stagnation in fundamental developments in engineering. Contrary to what the young'uns think, there is very little that's appeared on the software scene that wasn't already there - and written more efficiently - either on the desktop in the '90s, or on the mainframe/cloud in the two decades prior. But what we do have is a whole pile of paperwork, of admin, of things to remember about how you're supposed to be doing things, of new ways to make creativity just that little bit harder.

So there is an *explosion* on all the new platforms of very similar software products, all developed the same way.

Stop it. Find out what works in your organisation, and evolve incrementally. Don't look to claims of revolutionary buzzwords.

Listen to the sysadmins

[mitcheli]

Seems to me that when I'm working on a build with security in mind, I start with a bare build that is the barest of essentials to boot the system and use the hardware. From then, we add on the packages we need to get just what we need. And as we layer those packages on, we focus on the hardening of the individual services. As time has gone on, in a virtualized environment, it's very easy to build "default" systems that fill certain roles and are sized for different resource levels. It would seem to me that these standardized baselines would serve well for an installation model. Fedora does that to some extent (loosely) but that could be built upon more I would think. So if I want a firewall, I could get a bare boned installation with enhanced iptables rules and hardening provisions commonly used. Or if I want a web server, perhaps a slightly less bareboned installation with the needed scripting tools (PHP, Perl, etc?), etc... It seems the biggest questions I've dealt with when building new systems is, role, size, and whether or not it's for development. Outside of that, the builds are rather typical.

Re:Marketing not cutting edge

[msclrhd]

Packaging in this sense is referring to grouping the built binaries and other files into a set of installable files that you can install (i.e. the rpm files in Fedora, deb files in Debian and msi files on Windows). These take care of specifying the dependencies and upgrades.

The discussion in TFA is how to group those packages so they are more manageable. For example, a core layer is critical for running the OS (containing the kernel and other essential software), like the projects built in the Linux From Scratch manual.

This then allows those groups to update and release independently of each other. These updates ensure that the packages in the group work well together. That is, you usually need to make sure that gcc, binutils and glibc all work well and update together so they would be in a group together.