9:46 a.m.
WG meeting will be at 12:00 UTC (07:00 EST, 13:00 Brno, 7:00 Boston,
21:00 Tokyo, 22:00 Brisbane) in #fedora-meeting on Freenode.
= Topics =
* Fedora Rings
* revisit the plan around rings
* interpret rings with users' use cases and requirements
* sync on where SCLs, copr, languages repositories etc. fit into
rings ideas
* Chairman for next meeting
* Open Floor
8:09 a.m.
Env & Stacks WG is going to define (hopefully) some more concrete Rings
plans on tomorrow's meeting. Expecting to be an interesting discussion,
important enough for wider audience, let me crosspost the invitation
also to other working groups.
(we're aware of not very friendly time for US folks, but it doesn't seem
worth changing the time-slot before the elections, since we're gonna do
it after the elections anyway; feel free to use the mailing list
env-and-stacks(a)fp.o instead)
Honza
On 01/12/2015 04:46 PM, Honza Horak wrote:
WG meeting will be at 12:00 UTC (07:00 EST, 13:00 Brno, 7:00 Boston,
21:00 Tokyo, 22:00 Brisbane) in #fedora-meeting on Freenode.
= Topics =
* Fedora Rings
* revisit the plan around rings
* interpret rings with users' use cases and requirements
* sync on where SCLs, copr, languages repositories etc. fit into
rings ideas
* Chairman for next meeting
* Open Floor
_______________________________________________
env-and-stacks mailing list
env-and-stacks(a)lists.fedoraproject.org
https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks
8:25 a.m.
----- Original Message -----
Env & Stacks WG is going to define (hopefully) some more concrete
Rings
plans on tomorrow's meeting. Expecting to be an interesting discussion,
important enough for wider audience, let me crosspost the invitation
also to other working groups.
(we're aware of not very friendly time for US folks, but it doesn't seem
worth changing the time-slot before the elections, since we're gonna do
it after the elections anyway; feel free to use the mailing list
env-and-stacks(a)fp.o instead)
And the nomination period is open [1]!
[1] http://fedoraproject.org/wiki/Env_and_Stacks/Nominations
Jaroslav
Honza
On 01/12/2015 04:46 PM, Honza Horak wrote:
> WG meeting will be at 12:00 UTC (07:00 EST, 13:00 Brno, 7:00 Boston,
> 21:00 Tokyo, 22:00 Brisbane) in #fedora-meeting on Freenode.
>
> = Topics =
> * Fedora Rings
> * revisit the plan around rings
> * interpret rings with users' use cases and requirements
> * sync on where SCLs, copr, languages repositories etc. fit into
> rings ideas
> * Chairman for next meeting
> * Open Floor
>
> _______________________________________________
> env-and-stacks mailing list
> env-and-stacks(a)lists.fedoraproject.org
> https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks
_______________________________________________
env-and-stacks mailing list
env-and-stacks(a)lists.fedoraproject.org
https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks
7:46 a.m.
New subject: Meeting minutes for Env-and-Stacks WG meeting (2015-01-14)
============================================
#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
11:42 a.m.
New subject: Meeting minutes for Env-and-Stacks WG meeting (2015-01-14)
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
11:23 a.m.
New subject: Meeting minutes for Env-and-Stacks WG meeting (2015-01-14)
These are really interesting ideas, even if I don't understand all
physics equivalences :)
About the amount of man-hours needed for any different model, I think
the current model does not require little amount of man power at all,
I'd rather say keeping all things work nicely together require actually
quite substantial amount of knowledge and time fixing compatibility
issues. Decoupling could help to see and fix the issues.
However, as we start decoupling things, I see there might arise new
challenges regarding compatibility of those parts -- which is actually
where I see the discussions about rings model should give us some
answers and we should find a way how to ensure the compatibility with
reasonable amount of man-power. Anyway, I agree that in case we find it
requires too much resources, it should be a reason to change the concept.
Honza
On 01/16/2015 06:42 PM, Pete Travis wrote:
On Jan 14, 2015 6:46 AM, "Honza Horak" <hhorak(a)redhat.com
<mailto:hhorak@redhat.com>> wrote:
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
5:25 a.m.
New subject: Meeting minutes for Env-and-Stacks WG meeting (2015-01-14)
On 21 January 2015 at 03:23, Honza Horak <hhorak(a)redhat.com> wrote:
These are really interesting ideas, even if I don't understand
all physics
equivalences :)
About the amount of man-hours needed for any different model, I think the
current model does not require little amount of man power at all, I'd rather
say keeping all things work nicely together require actually quite
substantial amount of knowledge and time fixing compatibility issues.
Decoupling could help to see and fix the issues.
However, as we start decoupling things, I see there might arise new
challenges regarding compatibility of those parts -- which is actually where
I see the discussions about rings model should give us some answers and we
should find a way how to ensure the compatibility with reasonable amount of
man-power. Anyway, I agree that in case we find it requires too much
resources, it should be a reason to change the concept.
One thing to keep in mind is that when we talk about "Stacks" in the
Environments & Stacks model, the idea is that Fedora is responsible
for providing the *base* of the stack, and potentially tools for
application level dependency management within the stack. What we're
*not* responsible for is integration testing *of* the stack.
The whole point of this is to provide a layer where Fedora as a distro
provider says "above this point, the onus for integration testing and
security updates is on the application developer, not the distro".
*Within* Fedora, we should *not* be providing divergent copies of
applications. httpd should be httpd, regardless of whether you're
running Workstation, Server or Cloud.
But a developer may choose to do their own integration testing and use
a httpd Software Collection, rather than the one integrated directly
into the Fedora platform. They'd then gain the benefit that their SCL
based project could use the *same* SCL to also run on supported
versions of RHEL and CentOS, rather than just on Fedora. However,
they'd have to build and test their own packages to run *on top* of
the SCL, or use a non-RPM dependency management system like pip, cpan
rubygems, etc for the application components.
Regards,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
8:31 p.m.
New subject: Meeting minutes for Env-and-Stacks WG meeting (2015-01-14)
On Jan 21, 2015, at 6:25 AM, Nick Coghlan <ncoghlan(a)gmail.com>
wrote:
*Within* Fedora, we should *not* be providing divergent copies of
applications. httpd should be httpd, regardless of whether you're
running Workstation, Server or Cloud.
I completely agree, I think it will get very confusing if we start shipping different
versions of standard packages
Cheers
Stu
10:26 a.m.
New subject: Meeting minutes for Env-and-Stacks WG meeting (2015-01-14)
----- Original Message -----
> On Jan 21, 2015, at 6:25 AM, Nick Coghlan <ncoghlan(a)gmail.com> wrote:
>
> *Within* Fedora, we should *not* be providing divergent copies of
> applications. httpd should be httpd, regardless of whether you're
> running Workstation, Server or Cloud.
I completely agree, I think it will get very confusing if we start shipping
different versions of standard packages
I agree that we shouldn't provide different copies, but I think providing different
configs (== httpd.conf) for different flavours makes a lot of sense.
Slavek
Cheers
Stu
--
Regards,
Slavek Kabrda
4:35 a.m.
New subject: Meeting minutes for Env-and-Stacks WG meeting (2015-01-14)
On 23 January 2015 at 02:26, Bohuslav Kabrda <bkabrda(a)redhat.com> wrote:
----- Original Message -----
>
>
> > On Jan 21, 2015, at 6:25 AM, Nick Coghlan <ncoghlan(a)gmail.com> wrote:
> >
> > *Within* Fedora, we should *not* be providing divergent copies of
> > applications. httpd should be httpd, regardless of whether you're
> > running Workstation, Server or Cloud.
>
> I completely agree, I think it will get very confusing if we start shipping
> different versions of standard packages
I agree that we shouldn't provide different copies, but I think providing different
configs (== httpd.conf) for different flavours makes a lot of sense.
Yeah, that makes sense. And if folks want to easily run things with a
Server or Cloud config locally on their workstation, then that's
something we'll be aiming to handle with containers.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
3383
days inactive
3394
days old
env-and-stacks@lists.fedoraproject.org
9 comments
6 participants
participants (6)
-
Bohuslav Kabrda -
Honza Horak -
Jaroslav Reznik -
Nick Coghlan -
Pete Travis -
Stuart Campbell