RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk)

[Matthew Miller]

On Mon, Jul 22, 2013 at 03:14:04PM +0100, Richard W.M. Jones wrote:
> On Mon, Jul 22, 2013 at 09:38:54AM -0400, Matthew Miller wrote:
> >   * E.g.: Everything in @standard, plus the toolchains to build it
> How about, like RHEL, the "toolchains to build it" goes into an
> RHEL-Optional-like separate place?  If it has to be in the core ring
> then either the core ring has to be really big with compilers and
> language runtimes and stuff; or we have big arguments about whether
> {Perl,Ruby,other specialized language/tool} can be used to implement
> core components.

Yeah, that's one of the other possibilities. Right now, obviously Python
_is_ used to implement core components. It's possible that popular
provisioning tools like Puppet and Chef really belong in the Ring 1 design
too, in which case we'll have to accept Ruby as well. In that model, the
"system Ruby" would be solely in service of other components in Core, and
independent of the Ruby stack used for applications.


> >   Ring Zero: Fedora Minimal
> > This is pretty self-explanatory.  There is a lot of demand and many
> > use cases for a "Just Enough Fedora" operating system. Ring 0 exists
> > to provide that in a serious way which Fedora has never really
> > covered before.
> Perhaps self-explanatory for you, but not for me!  What are the actual
> stated goals for this that are different from the small @standard
> ring?

Well, "not self hosting" would be one. :)

Goals would include

 - minimizing on-disk space
 - minimize chances of needing to respin for security updates
    (e.g. by segregating dependencies so we don't pull in various libs)
 - minimize footprint of running processes 
 - modularizing translations and documentation
 - while still being a base that other things can build on

> >   * Start from the current @core, and aim to shrink
> Aim to shrink ... to what?  Nothing?

Something like "kernel + init + some way to log on + some way to install
things".

> >   * Intentional focus on minimalism 
> You don't *need* bash if you have a way to upload a binary, because
> everything can be done by uploading a binary.  So maybe the minimal
> thing is kernel + scp + a port of CP/M's CCP (I'm trying to perform a
> reductio ad absurdum on this ...)

Once we get to "porting CCP" we've hit the absurdum, I think. Instead, we'd
use the equivalent minimal things _which are still Fedora_.


> >   What's a Ring?
> >   ---
> >   * Rings give SIGs a way to replace the default expectations with their own
> >   * Separate policies may apply to each ring
> >   * But also, also, we need community, policies, and infrastructure to make
> >     them _part of Fedora_
> Is a ring also a yum repo?  If so, how do you express dependencies
> between these new repos?  eg. My package needs OCaml and Perl 5 to
> build, so I want those [repos?] as dependencies.

OCaml and Perl 5 would be software stacks within Ring 5. A software stack
might be implmented as a separate yum repo. For development, you might
simply want to specify the dependencies at that granularity. For deployment
of the app, you probably want some more fine-grained way of saying exactly
what the specific modules needed are.



> I'm having difficulty understanding the nuts and bolts of how this
> will work, especially when you say "Not necessarily even RPM".

Here's one model which I hope will make that concrete:
https://www.openshift.com//developers/cartridge-authors-guide


> > Some approaches may even move beyond RPM packaging. This can mean
> > focusing on "language native" package formats like Jars, Gems, and Eggs;
> > or it can mean moving to a Git-based distribution model for some parts
> > of the distro.
> I suspect this would be better if we made it much easier to automate
> "cpan2spec"-style mass importing of packages to RPM.  So that, for
> example, you didn't need to separately review every single perl-*
> package that comes from CPAN, or every single rubygem.  

Yes, definitely an approach worth looking into.

>                                                         (The obvious
> downside is that Fedora or Someone is going to be shipping an awful
> lot of dodgy, insecure, illegally-licensed software because all the
> checks we usually do to keep that out of the distro will be bypassed.)

Well, obviously Someone is doing that quite a lot anyway. Fedora needs to
continue to avoid that. Here is where "work with upstream" comes in -- if we
put the same effort into reviewing packages in Fedora into reviewing the
same code at the _upstream_ packaging point, we significantly increase the
amount of good our work is doing _and_ we can draw in a larger community of
people interested in the same ends but not necessarily in Fedora or RPMs.



-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm at fedoraproject.org>