On Jan 14, 2015 6:46 AM, "Honza Horak" <hhorak@redhat.com> wrote:
>
> ============================================
> #fedora-meeting: Env and Stacks (2015-01-14)
> ============================================
>
>
> Meeting started by hhorak at 12:01:10 UTC. The full logs are available
> at
> http://meetbot.fedoraproject.org/fedora-meeting/2015-01-14/env-and-stacks.2015-01-14-12.01.log.html
> .
>
>
>
> Meeting summary
> ---------------
> * hello-ing (hhorak, 12:01:44)
>
> * Fedora Rings (hhorak, 12:03:21)
> * LINK: http://mattdm.org/fedora/next/#15 (hhorak, 12:05:39)
> * LINK: http://mattdm.org/fedora/next/#20 (hhorak, 12:05:40)
> * there is no clear sense of the details of each ring.. e.g.
> definition, type of things in the ring, loose guidelines, users'
> expectations, motivation to use the rings (hhorak, 12:18:13)
> * IDEA: ring2 may be split into ring 2 and ring 3 - the new ring 2
> should contain only system high-level stacks (we'll always need
> system versions of e.g. interpreted langauges) and ring 3 should
> contain copr/playground and possibly also upstream-type of repos
> (hhorak, 12:18:17)
> * ring 0 is a minimal bootable system - basically the domain of the
> Base WG (hhorak, 12:33:37)
> * IDEA: question is what can be moved out of ring 1 to ring 2?
> (hhorak, 12:40:13)
> * IDEA: the "promotion" idea.. as in ... the lower the number of ring
> the higher quality of the package and the more it must be maintained
> (hhorak, 12:40:13)
> * IDEA: definition of ring 1 is a minimal set of packages that give
> you a functional system, with some sort of approval (hhorak,
> 13:31:21)
> * IDEA: ring 1 should be self-hosted -- because you want to build very
> solid important packages using very solid important packages
> (hhorak, 13:31:21)
> * IDEA: WG-wkstn may want to package httpd differently than WG-server
> -- that could be solved on configuration - level like httpd-dev and
> httpd-prod (hhorak, 13:31:21)
> * IDEA: then ring 2 includes clean/good pkgs of other stuff; ring 3
> good pkgs but not complete; ring 4 any old stuff (hhorak, 13:32:31)
> * IDEA: topic for ML or some of the next meetings: setting some
> technical expectations about how to differ ring 0, 1, 2.. (hhorak,
> 13:40:44)
> * IDEA: topic for ML or some of the next meetings: look more closely
> on users' wok-flow -- say he wants to develop or use some app from
> ring X -- what it actually means in practice.. (hhorak, 13:40:44)
>
> Meeting ended at 13:45:30 UTC.
>
>
>
>
> Action Items
> ------------
>
>
>
>
>
> Action Items, by person
> -----------------------
> * **UNASSIGNED**
> * (none)
>
>
>
>
> People Present (lines said)
> ---------------------------
> * juhp_ (69)
> * bkabrda (64)
> * langdon (50)
> * hhorak (45)
> * vpavlin (28)
> * zodbot (4)
> * jzeleny-mtg (1)
> * samkottler (0)
> * tjanez (0)
> * sicampbell (0)
> * juhp (0)
> * ncoghlan (0)
> * pkovar (0)
>
>
>
>
> Generated by `MeetBot`_ 0.1.4
>
> .. _`MeetBot`: http://wiki.debian.org/MeetBot
> _______________________________________________
> env-and-stacks mailing list
> env-and-stacks@lists.fedoraproject.org
> https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks
I'm reading the 'rings' model as somewhat analogous to the Bohr model of the atom; concentric rings, with each element on a given ring following the known circular path.
In practice, the theory more closely follows the modern orbital model of the atom, where more volatile elements end up in the more outer layers but have their own vector within that layer. It's a model that I think more closely parallels the goal here, which I'm inferring is to allow the less critical packages to follow a more divergent path.
Call it inexperience, but I have trouble conceiving how extended implementation of this goal will scale. Moving from a general "Everything should work nicely together, even if it requires compromise" to "Some things can diverge instead of compromise, within reason" sounds like a path where the various permutations of package and library interactions can become overwhelming. As with the orbital model, I can envision that quantifying the state of an "electron" - package, package set, language, whatever - will be an exceedingly difficult task where not all factors can be known.
Unlike the orbital model, I think we want elements to move inward as more energy is invested, not outward. What I initially interpreted as a model for providing developers with a graduation path now seems like a fragmentation path, where, using the example cited above, a developer can work with httpd-dev on Fedora Workstation and experience unexpected problems when deploying to httpd-prod on Fedora Server and still more when deploying to Fedora Cloud or some unflavored instance. Avoiding those problems when fragmenting at scale is going to require a massive amount of analysis, and I have reservations about whether the community can provide the man-hours and motivation required.
--Pete