On Mon, Jul 22, 2013 at 09:21:39AM -0600, Kevin Fenzi wrote: > 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. Ah yes, Fedora Bob. Just in line with what Microsoft is doing! http://news.cnet.com/8301-10805_3-57593736-75/bill-gates-says-microsoft-bob-will-make-a-comeback/ :) [the following has much trimming as I reply to specific points. Hopefully I haven't over-trimmed] > > * 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. True. Some of these things I expect to grow as we enable them. I don't think it will be there immediately. > > * 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. One model I have for this kind of disruption is the Innovation Schools process in Massachusetts. (Since I have kids in elementary school...) This is an in-school-system alternative to a charter school, where an individual public school can be established (or converted) to do things differently from district policies. Here, there are six different "areas of autonomy", allowed and in each case you have to list which autonomy you're asking for -- in the school case, curriculum, scheduling, staffing, etc. Here, it'd be the examples above and whatever else. This is the point on a different slide that we need the policies to make this ring part of Fedora. So, a practical follow-up to this proposal would be a committee to design the policies for Ring 2 and how they work. > Person with one package management system always knows whats > installed. Person with 5 is never sure. I expect that for practical use, five might be available but users would pick one. (Or in some cases two -- one for managing the base and one for what's on top of that.) > Do we need a more formal definition of a SIG? Right now it's... anyone > who calls themselves that. Possibly. > How do we handle resources for these Rings? Can you define "resources" more specifically in this context? > 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. Here, I'm appealing to the broad charter given by Fedora's mission, which is "The Fedora Project's mission is to lead the advancement of free and open source software and content as a collaborative community." The distribution itself as we make it today is much narrower than that. There's plenty of room under the umbrella for us to include things in Fedora outside of what we do now. > > 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? Absolutely. I think the Formulas approach is particularly suited to that; we can provide the basic tools, and hopefully a collaborative library of packaged solutions, but we don't necessarily provide the bits. > The problem with doing this stuff as an OS, IMHO, is that there's a > combitorial explosion in support and maintenance. *nod* Need more clarity in what combinations are sensible / supported. > > 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? Yes, although the critical path is currently focused on installation and distro composition, so while there is some overlap, there's also some mismatch. > > 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? ;) Hopefully some of the Software Collections people can elaborate more on what they need. I think "built in and distributed with Fedora infrastructure" is roughly what I mean. > 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. The non-rpm section is definitely the scariest. And I hear you on the SIGs and work. Thanks for the feedback! -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm@xxxxxxxxxxxxxxxxx> -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
