On Mon, 22 Jul 2013 09:38:54 -0400 Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote: <snip core platform, etc stuff which seems mostly reasonable> I do agree that "Core" will cause some people to blink, but I realize it's just a label. We could call it "Base" or "Platform" Or "OS" or "bob", it doesn't bother me too much. > What's a Ring? > --- > * Rings give SIGs a way to replace the default expectations with > their own A lot of the proposals and posts I have seen lately have talked about giving SIGs more power and ability to do what they want. However, traditionally in Fedora SIGs have been very loosely setup and it's not clear to me how active most of them are. I could be wrong, but it kind of sounds like people are wanting to shove off work to SIGs that may or may not exist or be able to do the work. > * Separate policies may apply to each ring > * But also, also, we need community, policies, and infrastructure > to make them _part of Fedora_ > > So, there's nothing really magical about the circles. The main idea > is that we need to make room for more exploration within Fedora > beyond the traditional idea of how a Linux distribution is put > together, and this is a model for describing how and where that can > work. > > We still need global Fedora policies, but they'll apply differently > to each ring. In Ring 2, SIGs will be given a lot of room to develop > their own rules, but in Ring 1, not so much. Different environments > and stacks within Ring 2 may have different individual policies from > each other, but there will also be general policies for Ring 2 which > are different from those for Ring 1, and of course global policies > that apply to the whole thing (e.g., no proprietary code). > > Possible Examples > --- > * Possible example: bundled libs okay, but must be documented ok. > * Can override versions of software at lower tier > * Can overlap with software from other stacks > * Not necessarily even RPM > * Different lifecycle (but shared release cadence) > > Big stuff here. I think these things would lead to a lot of Chaos. > Obviously, no-bundled-libs is a crucial part of the packaging > guidelines today. As a sysadmin, I know why it's important. This is > not just a noble goal, but also something that pragmatically makes > systems better. But, it's also keeping us from having software that > people really use in Fedora. Chef and Hadoop are two big examples. > This hurts us more than it helps the world. So, in some areas, we > need a different approach. I might be open to relaxing that somehow... > > Overriding other parts of the distribution is crucial, and I'll talk a > little bit more about different approaches and what they mean in a > little bit. It might be important to some, but it also means a lot more work. ;) > 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. Person with one package management system always knows whats installed. Person with 5 is never sure. > And, different lifecycle: a SIG may decide that Ruby 1.9.x support > should continue for some number of years and maintain that stack > against different Fedora Core releases. We do this already in some > ways, but having a clear split makes it feel more natural and will > make developers feel more confident. I suppose. > > SIG-centric > --- > * SIGs will form "bubbles" within this ring, possibly varying from > packaging guidelines in order to meet needs. > * Change management will also be SIG-focused. > > Fedora already largely works this way. We just need more of it. If we > can be more flexible about what it means to participate in Fedora, we > can increase the intersection with upstream communities. Do we need a more formal definition of a SIG? Right now it's... anyone who calls themselves that. How do we handle resources for these Rings? If they aren't using rpms, how are reviews done, packages imported to where, built where, signed where, etc? What about conflicts between rings? > Fedora Commons > --- > * The collection of packages outside Core following traditional > policies and practices > * We're not throwing that away > * Many people continue to be interested in this model > * Shared by other parts of Ring 2 where possible > > This is a special bubble within Ring 2. In fact, on Day 0, it still > is _all of_ Ring 2. The name here is mean to evoke Creative Commons; > we can discuss other possibilities too, of course. > > > Many Ways! > --- > * Software Collections > * Stacks 2.0 > * OpenShift Cartridges > * Fedora Formulas > * Traditional Packaging > > There are many different approaches people are working on right now. > I don't know which will ultimately be best. We want to enable the > experimentation, so we can find what succeeds. Some of these things > aren't beautiful, but if we can invite them in anyway, they can > iterate towards perfection. I like the idea, but I worry about calling all these things "Fedora" before they are really worthy of it, or before we know the scope of them. I like the idea of providing some place or resources as we can for them and let them hash out if they can come up with a supportable/sustainable model, then they could be considered for moving further into the Fedora ecosystem. > > Exploring Different Approaches > --- > * Packaged vs. DVCS > * Builds on Core vs. Overrides Core > * Replaces vs. Coexists > * Appliance vs. Shared > > It may be useful as we think about the different approaches to think > about the different philosophies they take. For example, there are > two different ways to "override" something. One is to actually > replace it — for example, your Fedora Formula may > replace /usr/bin/python with Python 3. The other is to install > multiple versions in parallel — using multi-versioned RPMs, or > Software Collections for whole stacks. In the future, a namespace > approach could even make /usr/bin/python be Python 3 for some > processes but not for the core OS. I think of these things as completely valid, but something end users would be doing. Couldn't we provide the tools and setup to easily allow people to do this, but let them do whatever they need for their needs? The problem with doing this stuff as an OS, IMHO, is that there's a combitorial explosion in support and maintenance. "I'd like to report a bug when you run formula foo and install the ruby 1.8 software collection with python3 rpm and the sysvinit pack" > Additionally, there's a natural distinction between things which > build on Fedora Core and may override Fedora Commons and those things > which may override both. As we explore these different approaches, it > may be useful to be intentional about which approach each SIG is > using. > > Ring Three: Applications > --- > * User-level installable > * Shift focus away from RPMs > * Linux Apps... or Git with OpenShift > > And, finally, the outside ring. This is end-user software. Exactly > how this will work is kind of further off, but it's important to > think about in the complete picture. We want to make this a nicer > experience for Fedora users, and we want to make it easier for > application developers to offer their stuff to Fedora. Sure, we should enable end users to do as they like with the best tools we can provide. No argument there. > > Part Three: Concrete Steps > --- > * What do we do to make this happen? > * What can be done now? > * What needs to be developed further? > > To make this not just all talk.... > > Three Next Things > --- > * Draw the "base design" for Fedora Core > * Make space for exploring Ring 2 innovation > * Emphasize upstream relationships (example: RubyGems.org) > > Much of this I hope to have further developed in the next few weeks > before Flock. I'll talk a little bit about these three now, though. > > First, I'm working on creating an example spin which would show a > basic suggestion for Fedora Core, both in a default install and an > everything-installed (including build deps) configuration. Right now, > if we take @standard + @core, that gives 430 packages from 330 > SRPMs... but recursively following the build deps explodes that to > 3915 packages from 1800 SRPMs. That's smaller than the 13.7K SRPMs in > all of Fedora, but bigger than would be ideal for the Core. And it's > probably not really the package set we want. So, I'd like to look at > that further, and I'll post more about that here as I do. Could you leverage the critial path here? > Second, we can make some changes to allow Software Collections to be > built for Fedora. There's more we can do with OpenShift. And we can > build up the Fedora Formulas idea. Basically, let's do all that. What do you mean by 'built for fedora' here? ;) I've sadly been completely swamped and not moved formulas forward much in recent months. Interested parties welcome to help. :( > And third, by increasing our engagement upstream, we can reduce our > own work. For example, right now RubyGems.org doesn't do any > validation of licenses, basic review for malware, or gem signing. If > we knew that this basic diligence was happening upstream, we could > extend our circle of trust. We've long had the mantra of "upstream! > upstream! upstream!" for code and patches — we can do the same thing > for packaging, for the same reasons and for similar benefits. (But to > do that, we need to work with upstream packaging formats rather than > demanding RPM — because experience shows that that doesn't work.) I think asking upstream communities to do those things, or at least do the parts that make sense would be great. > Conclusion > --- > > * Refocus Core to provide a better platform for building on > * Make room for innovation at the "Ring 2" level > * Empower SIGs to create solutions that fit > * Won't break what we have > * And we can start right now > > So there we have it. Comments and discussion, please! I'm not against the idea, but am worried about the non rpm sections and how much SIGs will be able to work on things. kevin
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
