On Mon, Jul 22, 2013 at 11:45:22AM -0600, Kevin Fenzi wrote: > > 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. ;) Absolutely. I am in no way suggesting we _also_ redesign the governance model. Such a committee would be authorized by FESCO and work together with the FPC. > > 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. That might happen on a system very overloaded for multiple purposes. Generally, I don't think we'd want to encourage it, just like we don't encourage 'everything' installs now. > Well, with my infrastructure hat on, I'd be first talking about > infrastructure resources. Say a SIG formed around gitlab, and said: We Let me interrupt right there. :) I'm not suggesting that we have sigs around particular applications. SIGs would be (as they are now, actually) around the different langage stacks and environments. On the gem example in specific, I don't think there would be any win in converting _our_ infrastructure to making gems. Instead, we'd work to build greater trust in upstream, so that we'd have the same level of confidence that a signed gem from rubygems.org is licensed properly, free of malware, and traceable to the owner as we do for current Fedora RPMs. Then, we could have more transparent gem-to-rpm tools (or even use RPMs possibly generated by rubygems.org with Fedora as a target) for the install-as-root cases, and possibly eventually develop infrastructure around Bundler for managing gems with trusted signatures, regardless of their proximate install source. But in any case, we'd start small and build up to it. > 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. Right -- very little. > > 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. I think this is an okay first direction, but I don't think it delivers enough of what people need. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm@xxxxxxxxxxxxxxxxx> -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
