14:44:02 <stickster> #startmeeting Architecture for a More Agile Fedora
14:44:02 <zodbot> Meeting started Sat Aug 10 14:44:02 2013 UTC.  The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:44:02 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:44:14 <stickster> [mattdm starts by describing what's great]
14:44:36 <stickster> Great tech, great people, high technical standards, best enthusiast distro and a solid base for a successful commercial product (RHEL)
14:44:39 <stickster> Decent cloud image
14:44:40 <stickster> BUT
14:45:04 <stickster> If we keep solely on the path we're doing now, we will become irrelevant because technology trends aren't standing still
14:45:22 <stickster> Even RHEL users aren't making enough use of Fedora
14:46:29 <stickster> Including Red Hat itself, when it comes to products other than RHEL!
14:46:40 <stickster> We are not being good to the whole world if products inside Red Hat aren't finding Fedora useful!
14:46:51 <stickster> The whole world is looking increasingly like those products
14:47:08 <stickster> Matt's idea:
14:47:20 <stickster> Focus core distro as a platform, include layers on top to suit specific cases
14:52:33 <notting> ...
14:52:55 <stickster> Ring 1: Draw a line around a small base design
14:52:58 <notting> (transcriber reconnects)
14:53:00 <stickster> This ring would include the strictest change management, and hold to current strong Fedora packaging standards
14:53:06 <stickster> Bsae functionlaity and stuff that should be expected of any Fedora system -- focus for engineering resources, a solid foundation
14:53:10 <stickster> It's basically "Fedora Core."
14:53:13 <stickster> YES, you read that right.
14:53:15 <stickster> But this is NOT a return to Core + Extras!  Only the name is similar, the model is NOT.
14:53:19 <stickster> The old model in the pre-unified Fedora days was based on "who," this is based on what
14:53:22 <stickster> Essentially Fedora Core was less open sourcey than either Fedora today or this new ring model.
14:53:26 <stickster> [stickster: I might call this Core Mk I vs. Core Mk II in this transcription to be clear]
14:53:41 <stickster> Ring 2: Builds around the foundation
14:53:53 <stickster> Don't panic, but we need to MOVE NOW to make this happen
14:54:11 <stickster> And we can get started now -- we have some specifics for Ring 1 but need to work out how the Ring 2 stuff works
14:54:15 <stickster> (and higher)
14:54:26 <stickster> It's a POLICY model, not an OS layer model
14:54:49 <stickster> Rings provide SIGs the way to replace default expectations, with separate policies, but be tied together by infrastructure
14:55:18 <stickster> Ring 2: Environments and Stacks -- where you run the code you care about -- modular collections of software used by other software (a little vague, and you could argue what's env vs. stack)
14:55:42 <stickster> Environments: e..g Desktop environments, ideally with app containers so we can host more untrusted apps without risking stability of host system
14:56:03 <stickster> Integrating OpenShift Gears for instance
14:56:22 <stickster> Another exapmle: Core image such as that used for a cloud guest
14:56:34 <stickster> Stacks examples: languages, databases, libs.... maybe even Wayland
14:56:47 <stickster> (These look a lot like OpenShift cartridges or software collections)
14:57:37 <stickster> Examples about Ring 2 policy:
14:57:41 <stickster> Bundled libs might be OK!
14:58:23 <stickster> "Worse is ultimately better as a survival mechanism"
14:59:18 <stickster> Otherwise people just don't want to use Fedora, because we are useless for them. The world has voted on what they want.
14:59:48 <stickster> Software in Ring 2 might override software at a lower tier. E.g. puppet, version of Ruby is too new on Fedora for that, yet everyone loves puppet, so supporting it is good for Fedora.
15:00:22 <stickster> Not necessarily even governed by RPM at this layer, would be good though if we can identify and catalog what's on the system where appropriate.
15:01:43 <stickster> For instance, people using npm & ruby gems, python pip, php pear, etc...
15:03:41 <stickster> Ring 2 is SIG centric.
15:03:52 <stickster> SIGs could have their own packaging guidelines, change management policies.
15:05:08 <stickster> Fedora Commons: a collection of packages outside Core that would still follow Core-like policies/practices
15:05:21 <stickster> People could keep doing that if they like. Many people will probably want to do this because they're used to the way Fedora works
15:05:32 <stickster> Could be shared with other Ring 2 participants where possible
15:05:38 <stickster> But not imposed on anything else in Ring 2
15:06:49 <stickster> [funny stuff about unicorns]
15:09:31 <stickster> Many ways to get things into Fedora this way, easier than before
15:09:49 <stickster> Software collections is a currently-ready thing
15:09:57 <stickster> Stacks 2.0... no so much, but it *will* be ready in the future
15:10:12 <stickster> OpenShift cartridges is another methodology we'll be able to accommodate
15:10:33 <stickster> Fedora Formulas -- currently only ideaware, but scripts that would automatically configure your system to handle some use case
15:10:41 <stickster> Traditional packaging -- yes, this will still work too!
15:12:08 <stickster> coprs will also help glue things together here, but in a bit of limbo in wake of skvidal's passing
15:12:15 <stickster> We are looking at how to make it happen
15:13:00 <stickster> Different ways to approach the problem logistically -- packages vs. DVCS; builds on Core vs. overrides/replaces Core
15:13:41 <stickster> There's a Ring 3 too
15:13:42 <stickster> Applicaitons
15:13:47 <stickster> [sp]
15:14:24 <stickster> User-level installable bits, shifts away from RPMs to something more user specific, like apps on a multi-user device (newer Android 4.x, git w/OpenShift, etc.)
15:15:10 <stickster> [picture of rings 0 + 1 + 2 + 3]
15:15:34 <stickster> [stickster: Should note, I missed on Ring 0 earlier -- that's the central OS only, i.e. kernel + most basic libs like glibc]
15:15:50 <stickster> [i.e. what you need to boot/start the system]
15:16:20 <stickster> So what do we need to do to make it happen
15:16:43 <stickster> 1. Draw 'base design' for Fedora Core -- deliverable for F21!!!
15:17:03 <stickster> Working roup to explore Ring 2 innovation, the policy, logistics and technical issues
15:17:10 <stickster> 2. Working roup to explore Ring 2 innovation, the policy, logistics and technical issues
15:17:37 <stickster> We haven't designed a coherent platform so we need to define that in concrete terms
15:18:34 <stickster> We frustrate people by not giving them that info
15:21:13 <stickster> [great point from Nate about the things in new Ring 1 is just what's required to enable Ring 2 to happen... might not even include RPM, some Ring 2 won't need that!]
15:21:56 <stickster> Rather than making review of the source licensing, other important packaging things part of a Fedora-specific workflow, we do it *upstream*
15:22:05 <stickster> e.g. http://rubygems.org
15:22:57 <stickster> We trust upstreams quite a bit right now, our packaging methods help us establish that... but if we work that upstream, we have same trust but it's more collaborative
15:23:55 <stickster> Very touching note on how skvidal influenced some of this work
15:24:49 <stickster> [concern from tflink about how we approach QE, sounds like an enormous explosion]
15:25:02 <stickster> [some responses saying this actually reduces the QE surface by contracting core]
15:28:37 <stickster> [Interesting conversations explode, but clearly everyone is very interested in this topic!
15:28:40 <stickster> ]
15:28:52 <stickster> [stickster: Transcription ends here, hope this helps people.]
15:28:53 <stickster> #endmeeting