On Mon, 22 Jul 2013 13:03:45 -0400 Matthew Miller <mat...@fedoraproject.org> wrote:
> [the following has much trimming as I reply to specific points. > Hopefully I haven't over-trimmed] No worries. I will do trimming as well. > > > * 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. Sure. Of course you mean, design the policies and get feedback and then get approval from fesco/Board. ;) > > > 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.) Well, or you are going to have to use whatever the SIG/whatever uses right? so, base with rpms, then add some other rpms, then a SCL for something, then you need some gems, etc. I just don't see how this could be supportable in the long run, unless we were very clear and narrow what could overlap and who is supporting it. > > 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? Well, with my infrastructure hat on, I'd be first talking about infrastructure resources. Say a SIG formed around gitlab, and said: We need a buildsystem to build gems and sign them, mirror and distribute them and an updates system for updating them. If we can't use our existing infrastructure since it's rpm centric, someone would have to write this code, test it, deploy it and maintain it. It would need machines and mirror space and release engineering and qa and a bunch of things. We simply don't have that in existance and negative cycles to create and maintain such a thing. The next thing someone will say is: "Oh, each sig can write and maintain their own thing". Thats bad for lots of reasons. Many SIGs wouldn't have the person power to write and maintain things, or the experence doing so, or the desire to maintain them in a secure and sustainable manner, etc. So, IMHo, if we go the route of allowing/shipping/maintaining non rpm collections, we should be very clear up front what resources could be expected. > > 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. Sure, I don't disagree, as long as what these things are is clear and not "Fedora the OS". ...snip... > > > 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'd prefer a setup where some SIG defines a collection somehow and end users can grab that and build the collection locally and use it. Then support for that would fall on the SIG that created the definition. If we build them ourselves, that to my mind implies that we need infrastructure changes, releng buy in and qa buy in to test them and "Fedora the OS" supports them. Which I don't think is sustainable. Speaking as a package maintainer, I would not like to get a bug report like: "Hey, I installed ancient version of your foo package as part of this Software collection and someone compromised my machine because it had a vulnerability. Can you backport all the security fixes from the newest upstream version without any other changes for me, so it will keep working as I like in my Software Collection?" > > 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! Thanks for the discussion. kevin
signature.asc
Description: PGP signature
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
