On 09/02/2015 12:24 PM, Josh Boyer wrote:
On Wed, Sep 2, 2015 at 2:59 PM, Brendan Conoboy <blc@xxxxxxxxxx> wrote:
Re-sending this with a better title so people might read it ;-)
I read it last week. Perhaps the lack of commentary isn't because of
the title. It's because there is nothing new here. The proposal
boils down to "collection/classification of packages that are
important." There is nothing about how to actually start here. See
below.
Perhaps it's a combination of both, but the repost has definitely
gotten more replies. Comments inline below.
At Flock 2015 there was a 2 hour session on the subject of rings which
are basically policy zones inhabited by packages. Right now fedora
packaging has 1 policy, so the entire OS is in a single ring. Creating
more rings means creating more policies. By doing this Fedora can
become adopt the flexible to appeal to diverse development communities
and thus grow. The general consensus at Flock was that Environments
and Stacks should take the lead in helping to define new rings, and
especially how the rings interact. As a side note, everyone agreed
the word "rings" breaks down the further you get away from the center,
but nobody has come up with something better yet (Venns? Blobs?
Zones?). A week or so ago, a small Environments and Stacks meeting
took place where it was generally agreed that the Base working group
was the right place to define Ring 0. That brings us to this
morning's BaseWG meeting. I talked a lot so here is a rough recap
integrating a few of the questions and comments people had (Do read
the log if you have time!)
Right now the Fedora distribution is 1 ring, let's call it ring 1. The
distribution contains an operating system and numerous applications
that run on that operating system. When we talk about defining ring 0
we're really talking about distinguishing between the operating system
and the applications that run on top of it.
We want to go from this:
Ring 1: The Fedora Distribution
To this:
The Fedora Distribution:
Ring 0: The Linux Operating System
Ring 1: The Applications and Stacks
It seems quite modest, but working through the details on what this
means is hard. What is an operating system in the Linux context? Ring
0 will likely have the strictest set of policies of all the rings, so
we want to keep it as small as possible, but it is more than a minimal
install. These are the traits of rings in general and ring 0 in
particular as I see it:
The original incarnation of the Base WG defined this already. How
does your definition differ? For that matter, how does your
definition differ from the existing critpath concept that is already
implemented in bodhi?
These are good questions, but perhaps premature. Here's another: What
is the ongoing purpose of the current Base WG? This discussion may
serve as a focal point for some of its next steps. The discussion at
flock was, everybody wants to move forward with rings, but they need
to know the specifics, so that's what we want to accomplish. I would
like to see Fedora serve a broader base of users and new/existing
developer communities- rings in general can do this, but I've only
written about the ring0/ring1 split.
1. Ring 0 is a repository of rpm packages built in koji.
2. Ring 0 contains, but is not limited to, the minimal install of
packages to go from Power On to a login prompt.
Define login prompt.
Am thinking text login prompt, IE, served by systemd. Keeping GUI out
of ring0 seems desirable.
3. Ring 0 passes repoclosure on its own (Packages listed as hard
"Requires" in a ring 0 spec file are themselves are implicitly ring 0).
4. Ring 0 is not self hosting. Packages listed in "BuildRequires" do
not need to be members of Ring 1. This isn't ideal, but it's a
practical consideration.
These match the previous definition that the Base WG came up with.
Nothing came of that except the dependency reduction work that a few
people jumped into and Harald bravely carried on with.
Hopefully people aren't expecting everything to be brand new and also
somehow a good idea.
5. Ring membership is at the source package level, not the binary
package. If one source package's binary/noarch sub-package is in ring
0, all sub-packages are in ring 0.
Also the same as before.
Ah, but the compose question might be answered differently.
6. Ring 0 contains the minimal libraries that define the OS API/ABI,
such as glibc. This probably happens implicitly by #3, repoclosure.
7. Ring 0 contains the tools needed to update existing packages and
install new packages.
Which is where a lot of the bulk came from in the original definition.
This brings in python at a minimum. If by tools you mean "graphical
updaters" then you're almost back to Ring 0 being Fedora distribution.
So precise language is needed.
How about "1 CLI update tool such as DNF"
(Also, the original definition included Anaconda because you need
something to actually install Fedora Ring 0 with and that brought in
GTK, etc).)
Again, it seems really desirable to keep the GUI stack out of ring 0.
The implications for anaconda or compose policy are a good thing to
dig into. It may be that we need to separate ring package maintenance
policy from compose policy.
That's the starting point, but it is by no means comprehensive. The
OS probably provides specific services beyond the ability to login,
for instance. Which styles of boot are supported? Where does
installation infrastructure like anaconda land? This is equal parts
philosophy and practicality. Also, policies for ring 0 may differ
from what Base has previously adopted: Do we create a ring 0 minimal
compose since we already need to check repoclosure? This might be a
great way to refactor primary/secondary such that we can gracefully
transition i686 down and secondary arches up. Lots of opportunities,
much to consider.
That's what we said last time :)
What a relief, we're almost done ;-)
Seriously, I'm not meaning to dissuade you at all here. I'm
suggesting that you do NOT wait for lots of people to chime in on what
Ring 0 is and instead come up with a concrete definition for it.
That's the what. You're almost there.
Yes, but we want a thousand holes poked in it so we can improve it.
That's the goal here. And to bring about questions like "Will this
let us adopt $POLICY what previously was not possible?" because
defining rings is really just a boring mental exercise if it doesn't
lead to letting us do new cool stuff we've prevented ourselves from
doing previously.
What is going to get you the most commentary comes after that. The
why and how. Why is Ring 0 defined this way, and how is this proposal
going to change things within the Fedora project/Fedora distribution?
Answer those questions, particularly the impact to package
maintainers, and you'll get a lot more feedback. I promise.
Absolutely- thanks!
--
Brendan Conoboy / Red Hat, Inc. / blc@xxxxxxxxxx
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
