On Jan 14, 2015 6:46 AM, "Honza Horak" <hhorak(a)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...
.
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(a)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