env-and-stacks
LOGS
12:01:10 <hhorak> #startmeeting Env and Stacks (2015-01-14)
12:01:10 <zodbot> Meeting started Wed Jan 14 12:01:10 2015 UTC.  The chair is hhorak. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:01:10 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
12:01:16 <hhorak> #meetingname env-and-stacks
12:01:16 <zodbot> The meeting name has been set to 'env-and-stacks'
12:01:24 <bkabrda> hi!
12:01:32 <hhorak> #chair pkovar tjanez samkottler bkabrda hhorak juhp ncoghlan vpavlin sicampbell
12:01:32 <zodbot> Current chairs: bkabrda hhorak juhp ncoghlan pkovar samkottler sicampbell tjanez vpavlin
12:01:44 <hhorak> #topic hello-ing
12:01:54 <jzeleny-mtg> hi guys
12:01:57 <hhorak> Hi
12:02:11 <vpavlin> Hi
12:03:21 <hhorak> #topic Fedora Rings
12:04:37 <hhorak> So, this topic was slightly touched the last meeting and suggested by langdon to include on today's meetin.. I also heard an idea to more the rings idea forward was mentioned in other WGs as well.
12:05:39 <hhorak> For start let's refresh the original idea:
12:05:39 <hhorak> #link http://mattdm.org/fedora/next/#15
12:05:40 <hhorak> #link http://mattdm.org/fedora/next/#20
12:08:09 * langdon lurks and can only stay about 30 mins
12:08:24 <hhorak> We don't need to follow the original labels exactly I'd say, but it may help and as soon as they are not sufficient, we can add dimensions, other rings etc...
12:08:41 <juhp_> hi!
12:08:43 <hhorak> langdon: good morning, kind of hoping you can kick it off a bit :)
12:08:47 <juhp_> sorry to be late
12:10:09 <langdon> I guess I just didn't feel like there was a clear sense of the details of each ring.. e.g. definition, type of things in the ring, loose guidelines, etc
12:10:25 <langdon> as a result, I htink it is tough to make a call about something like scl
12:10:37 <juhp_> true
12:10:38 <hhorak> and user's way to use the rings..
12:10:53 <hhorak> langdon: that's my feeling as well.
12:10:58 <langdon> which ring does scl live in? (not really asking, just pointing out it is hard to answer)
12:11:37 <langdon> hhorak, also, user's why [sic] to use the rings
12:12:39 <bkabrda> I think what we're running into is, that we're still always have one system version of Python, Ruby, Perl, etc... meaning that ring 2 contains these system version and also additional versions
12:13:43 <bkabrda> so I think that ring 2 should be split into ring 2 and ring 3 - the new ring 2 should contain only system high-level stacks and ring 3 should contain copr/playground and possibly also upstream-type of repos (e.g. devpi that I'm still working on BTW ;))
12:14:04 <juhp_> bkabrda, I agree
12:14:27 <bkabrda> what I'm trying to say is that defined like this, ring 2 has a too wide definition
12:14:32 <langdon> bkabrda, so.. is it a property of ring2 that it must support diff versions of things?
12:15:05 <bkabrda> langdon: not sure I understand the question
12:15:14 * bkabrda needs more coffee
12:15:40 <langdon> well.. in your first stmt you said you need more than one version of py in ring2
12:16:04 <bkabrda> langdon: ah, I see, let me rephrase that
12:17:18 <bkabrda> I think we'll always need system versions of e.g. interpreted langauges, Python being one of them. the Python situation is quite unlucky because of the py2/py3 split and migration, but this should, in general, be kept to minimum
12:17:47 <bkabrda> so these minimal stack should be kept in ring 2, while other (possibly parallel) stacks should be moved to ring 3
12:18:08 <bkabrda> ring 3, in my mind, is a goto place for people who are not satisfied with the system version
12:18:13 <hhorak> #info 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
12:18:17 <langdon> bkabrda, ok so what is the diff between r0 / r1 and r2 for this?
12:18:17 <hhorak> #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
12:18:39 <langdon> like why is py not in r1?
12:18:48 * langdon plays devils advocate
12:18:59 <bkabrda> langdon: my perception of rings is
12:19:16 <bkabrda> ring 0 - the minimal set of packages to boot a system
12:19:31 <hhorak> (like the atomic or so)
12:20:02 <bkabrda> ring 1 - a minimal set of packages to get a system for a "non-developer" user, e.g. user who wants to browse web, write documents, run different apps etc
12:20:04 <juhp_> r1 needs to be self-hosting
12:20:39 <bkabrda> ring 2 - additional packages still provided in Fedora core, that extend ring 1. like python-whatever-extension-module-not-required-by-anything-in-ring-1
12:20:40 <vpavlin> juhp_: r1 or r0?
12:20:47 <juhp_> r1
12:20:58 <juhp_> r0 is not self-hosting - too small
12:21:38 <bkabrda> that's my perception of the concept
12:22:15 <juhp_> bkabrda, so iiuc correctly your python package would live in r1 (or r0 even?) but pythonXY would like in r2?
12:22:25 <juhp_> like = live
12:22:53 <langdon> r1 is enough for a "user"? i always thought that was a "slice" in r2
12:23:25 * hhorak not seeing reasons to split bkabrda's ring 1 and ring 2
12:23:47 <bkabrda> juhp_: that's actually a tough question, since it's not clear which one of the alternative pythons should live in 2 and 3 (the 3 that I proposed)
12:24:29 <juhp_> my interpretation is that r2 is more or less for scl like packages
12:24:45 <juhp_> bkabrda, okay, I meant so pythonXY not all :)
12:24:48 <juhp_> some!
12:25:18 <juhp_> bkabrda, or what would you put in r2?
12:25:38 <bkabrda> juhp_: as I've said, copr/playground, upstream repo mirrors (devpi) etc
12:26:00 * juhp_ re-reads
12:26:27 <bkabrda> but I think I'm starting to see what langdon is hitting at (hope that "hitting at" has the meaning I want to use right now ;))
12:27:12 <juhp_> bkabrda, okay sorry - then I don't understand what separates your r1 and r2
12:27:17 <hhorak> bkabrda: unless somebody is not hitting on anybody else we're fine
12:27:22 <juhp_> bkabrda, how can python not be a part of r1?
12:27:34 <bkabrda> juhp_: the system python would certainly be part of r1
12:27:35 <langdon> bkabrda, hinting at? (roughly, suggesting but leading)
12:27:41 <juhp_> ok
12:27:43 * langdon hits the keyboard
12:27:45 <bkabrda> langdon: ok, scratch that :)
12:28:23 <bkabrda> I guess the problem of my concept is not giving a clear distinction between content of rings 1 and 2
12:28:53 <langdon> well.. i think bkabrda is doing a nice job of pointing out why the rings need definitions :)
12:29:26 <bkabrda> langdon: :)
12:29:26 <langdon> how about this.. 1) write down rules for all the rings 2) plug pkgs in to the rings 3) fix rules where 2 breaks
12:29:41 <juhp_> bkabrda, I think I got confused by "so these minimal stack should be kept in ring 2"
12:29:41 <bkabrda> so why don't we start defining the rings together from number 0?
12:30:00 <hhorak> bkabrda: actually I don't see that as a problem, more as an implementation detail
12:31:02 <bkabrda> hhorak: what were you replying to exactly?
12:31:23 <juhp_> I think ring 0 is just base/core - basically the domain of the Base WG
12:32:27 <hhorak> bkabrda: sorry, slow writer :) it was about strict distinction in your ring 1/2 idea -- I don't see that as a big problem to not be able to distinct now
12:32:39 <hhorak> juhp_ +1
12:32:50 <bkabrda> yeah, so as I've said, let's start defining from the bottom
12:33:11 <bkabrda> juhp_: +1. to provide additional definitio, I'd call it a minimal bootable system
12:33:37 <hhorak> #info ring 0 is a minimal bootable system - basically the domain of the Base WG
12:34:08 <bkabrda> ok, so that was easy :) I guess ring 1 will be more tough than that
12:35:01 <juhp_> (no dnf/yum?:)
12:35:22 <juhp_> anyway I think we can move to ring 1, yes
12:36:00 <bkabrda> juhp_: I think dnf/yum isn't necessary in ring 0
12:36:30 <juhp_> bkabrda, it is in @core at least
12:37:28 <hhorak> ring 1 should include some basic libraries, tools, etc. for: upper ring and imho also for the minimal install of products..
12:37:29 <juhp_> maybe an interesting question is what can be moved out of ring 1 to ring 2?
12:37:44 <langdon> juhp_, +1
12:38:36 <bkabrda> juhp_: yeah, I see the problem. given user application X (say somenone packages askbot), should it go to 1 or 2?
12:38:37 <langdon> also , i would bring up the "promotion" idea.. as in ... the lower the number of ring the higher quality of the package and the more it must be maintained
12:38:44 <hhorak> and ring 2 is then what? (sorry, starting to loose a bit; shouldn't we use some other id than numbers for rings?)
12:39:34 * langdon needs to step away to catch bus, will be here intermittently
12:40:06 <juhp_> hhorak, yeah that may be good
12:40:13 <hhorak> #idea question is what can be moved out of ring 1 to ring 2?
12:40:13 <hhorak> #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
12:41:55 <juhp_> hhorak, but maybe we need to work what they are first :)
12:42:52 <hhorak> juhp_: sure :)
12:43:40 <juhp_> it is kind of tricky though
12:43:44 <hhorak> so I still don't see reason to split ring 1 and 2 unless the 2 is actually the stacks-ring already
12:44:05 <bkabrda> hhorak: let's stop thinking about splitting right now and focus on ring 1
12:44:09 * vpavlin sees a bit of chicken & egg problem here:)
12:44:27 <juhp_> let's say package X moves to "ring 2", but later package Y in "ring 1" needs to BR X - then we need to move X back into ring 1?
12:45:10 <bkabrda> juhp_: that is a good question. I still think that the most important question is "what packages go into ring 1?"
12:45:21 <juhp_> well my thinking was that ring 2 is the stacks-ring for stack that are not needed for ring 1 itself
12:45:53 <juhp_> bkabrda, ok
12:46:26 <vpavlin> "needs to BR X" - I think BuildRequires shouldn't be reason to pull pkg from higher ring to lower..
12:47:33 <bkabrda> my perception is, that there will be no "barrier" between packages from ring 0 and ring 1 (i.e. they'll all be built in one koji instance), but ring 1 and 2 might be separated (e.g. koji vs. copr), so moving packages back and forth might be an issue
12:48:19 <juhp_> right
12:50:10 <juhp_> one idea I had was ring 2 being a koji layer above ring 1 for stacks and ring 3 becoming copr etc if that helps
12:50:51 <bkabrda> and that's actually a problem, too. let's say someone wants to add a package to ring 1, e.g. python-foo or "mycooldesktopapp". who decides whether it should go into 1? will we tell the person "your package can't go into ring 1"?
12:50:58 <vpavlin> bkabrda: But you cannot depend with something built in Koji on something built in COPR, right? That means if we say COPR is Ring 2, package could move to Ring 1 only if they are properly accepted for Fedora..right?
12:51:18 <bkabrda> vpavlin: that's exactly what I was trying to say, yes :)
12:52:48 <juhp_> I can think of some minor/less used libraries or stacks that could probably be moved out of ring 1 but overall it seems pretty hard to split it up?
12:53:42 <bkabrda> juhp_: yes. and moreover, do we want to prevent people from adding new stuff to ring 1, even if it is a better candidate for going to ring 2?
12:54:07 <juhp_> bkabrda, right maybe we can't :)
12:54:33 <juhp_> unless there are some objective criteria
12:57:00 <juhp_> I guess one can also kind of think of some parts of ring 2+ as an "upstream" or test bed for ring 1
12:57:52 <juhp_> langdon, any more thoughts on ring 1?
12:59:56 <vpavlin> Maybe I am missing something but why we cannot just have ring0 - base/bootable system, ring1 - the rest of packages in Koji, ring2 - copr + devpi or whateever else we come up with..
13:00:18 <juhp_> good question
13:00:57 <bkabrda> vpavlin: but that also means that people can (and will) package pretty much antyhing into Fedora -> ring 1
13:01:33 <bkabrda> so there's pretty much no distinction between ring 1 and 2 except where the packages are built
13:01:47 <hhorak> vpavlin: that would mean we're fine with the current status, but are we?
13:02:20 <vpavlin> bkabrda: Yes..but if we don't want them to do that, we probably need a team of people checking content of ring1 vs. ring2 and moving packages around.
13:03:00 <bkabrda> vpavlin: true. but if we don't do that, what's the point of the rings? I thought that rings were supposed to specify type of content
13:03:09 <langdon> vpavlin, +1 .. isnt that the fpc?
13:03:27 <vpavlin> langdon: is it?:)
13:03:48 <langdon> and, personally, i do think you want people to want to be in a lower ring but be barred if they aren't "ready".. thats why i think you want rules
13:04:09 <juhp_> yeah
13:04:22 <vpavlin> So what about WGs specifying content of ring1 - f.e. Server should be able to do that WRT roles
13:04:32 <vpavlin> And then ring2 would be the rest
13:04:39 <langdon> i also think one needs to consider does r0+r1 = wkstn + r3-workstation? vs r0+r1 = server + r3-server??
13:04:52 <juhp_> vpavlin, that might make sense yes
13:05:22 <langdon> vpavlin, yes.. also pointing out the problem of the concept of "rings" when really it is more like a stack per flavor
13:05:22 <bkabrda> vpavlin: which leads back to my question - how do you prevent people from adding unnecessary stuff to r1? and if you don't what's the point?
13:06:02 <juhp_> I think r3 would be optional stuff?
13:06:13 <langdon> bkabrda, guidelines on pkg, fesco approval (or someone)... like r1 should be locked down .. not sure about r2
13:06:22 <vpavlin> bkabrda: How? content of rings being defined by WGs - you would have to ask for adition
13:06:52 <bkabrda> vpavlin: my point is, if there are no rules what you can or can not add to a ring, what's the point of having ring definitions?
13:07:26 <vpavlin> langdon: It actually sounds good to have it split by "product" as ring1 according to Server will look differently then to WS
13:07:42 <juhp_> we could say ring 1 is default Cloud + default Server + default WS perhaps
13:07:52 <juhp_> vpavlin, yes
13:08:08 <juhp_> though also a bit scary
13:08:08 * langdon realizes in the example above he meant r2-wkstation and r2-server
13:08:13 <vpavlin> bkabrda: I think the definition is always minimal set of packages that gives you functional system
13:08:14 <juhp_> ok
13:08:42 <bkabrda> vpavlin: so adding to ring 1 would have to go through some sort of approval, right?
13:08:47 * vpavlin has another meeting
13:08:50 <vpavlin> bkabrda: Definitely
13:09:01 <bkabrda> e.g. from a WG that works on that product
13:09:03 <langdon> juhp_, vpavlin i am just not sure if that split is at r1 or r2.. but if it isn't r1 then i guess what is the diff between r0 and r1.. unless it is that you can have more than one of a thing in r1
13:09:09 * langdon argues with himself
13:09:42 <vpavlin> r0 is Base WG product - minimal installable Fedora (Docker Base image + kernel?)
13:09:44 <juhp_> r1 seems the hardest to define
13:09:51 <vpavlin> r1 could be minimal for product
13:09:56 <bkabrda> so if we have minimal ring 1, all other packages should go to ring 2? if so, where is ring 2? is it copr/devpi kind of repos or is it also partially in koji?
13:09:56 <vpavlin> r2 the rest in Koji
13:10:06 <vpavlin> r3 copr + "stuf"
13:10:16 <bkabrda> vpavlin: that sounds reasonable
13:10:20 * langdon just to add to confusion .. we could have 5 rings.. or 10.. so .. we can scope the rings smaller
13:10:35 <juhp_> vpavlin, yeah I was also kind of thinking something like that
13:10:37 * vpavlin gets a bit of headache..
13:10:37 <langdon> bkabrda, i think r2 is still "koji"
13:11:00 * langdon runs rings around vpavlin's headache :)
13:11:21 <bkabrda> langdon: so what is the defintion of r2? it includes pretty much antyhing, but it has certain level of quality guaranteed, unlike ring 3?
13:11:35 <bkabrda> assuming ring 3 is what vpavlin said - copr + "stuff"
13:11:38 <juhp_> bkabrda, I think so
13:11:47 <vpavlin> bkabrda: r2 has to pass Fedora Review
13:11:52 <langdon> bkabrda, yeah.. no bundling unless scl (or scl-like)?
13:11:55 <bkabrda> I think I'm starting to like that
13:12:14 <juhp_> langdon, bundling means?
13:12:26 <langdon> vpavlin, is "fedora review" current review? or some lighter set of guidelines?
13:12:34 <bkabrda> so there is no distinction in content type between ring 2 and 3, the distinction is rather "quality" in terms of packaging, right?
13:12:41 <vpavlin> langdon: I would see it as current review
13:13:10 <langdon> juhp_, literally? carrying a binary that is already present in some other package because you want a diff/modified version.. "anti- shared library"
13:13:17 <vpavlin> We should still provide certain level of quality in Fedora...the low-quality-level stuff can go to r3, right?:-)
13:13:21 <langdon> bkabrda, +1
13:13:23 <juhp_> langdon, ah right
13:13:39 <juhp_> copy libs etc, okay
13:13:59 <juhp_> vpavlin, +1
13:14:33 <langdon> so.. i think y'all are close... but.. i think it should still be considered "in fedora" ish  in r3.. it is more like a path.. we want people to get to r1 or r2 but we don't want to exclude them if they aren't ready
13:15:10 <vpavlin> I can see r3 split into 2 in the future - r3 having some lightweight review, r4 becoming the low-level in quality..
13:15:24 <bkabrda> langdon: I think we want people to get to r2, since r1 is supposed to be minimal, but otherwise I agree
13:15:25 <juhp_> yeah r3 is kind of an incubator or experimental repo for fedora
13:15:28 <vpavlin> r3 having some lightweight (prefferably automated) review
13:15:30 <juhp_> vpavlin, aha
13:16:02 <vpavlin> juhp_ I think both our statement works fine
13:16:03 <langdon> so.. r0 = minimal to boot, not self-hosted; r1 = clean/good pkgs, must be approved by a WG; r2 clean/good pkgs of other stuff; r3 good pkgs but not complete; r4 any old stuff
13:16:12 <langdon> r4 does have license review though
13:16:31 <bkabrda> langdon: where did r4 come from? :)
13:16:46 <langdon> bkabrda, i like rings?! :)
13:16:47 <vpavlin> bkabrda: From me....but I said - in the future:)
13:16:57 <bkabrda> langdon: also, I'd add r1 is self-hosted
13:17:09 <bkabrda> at least I think it should be
13:17:10 <langdon> bkabrda, why?
13:17:23 * langdon semi-devil advocate
13:17:26 * vpavlin needs to go, don't get too wild guys;)
13:17:40 <bkabrda> langdon: because you want to build very solid important packages using very solid important packages ;)
13:17:53 <juhp_> bkabrda, I think it should be yes
13:18:09 <bkabrda> e.g. packages that build highly important stuff should also be considered highly important
13:18:13 <juhp_> vpavlin, cya
13:18:19 <bkabrda> s/e.g./in other words/
13:18:35 <bkabrda> langdon: makes sense?
13:18:44 <langdon> bkabrda, ok.. i don't disagree.. but maybe it is slices like wg-wkstation, wg-server, wg-cloud, wg-build ... so the build slice is shared and must be agreed by all WG?
13:19:15 <langdon> i guess i don't want a WG picking up a build pkg on the cheap.. :)
13:19:17 <juhp_> aha
13:19:36 <bkabrda> langdon: I'm not sure about slices. what about packages that are used by two or more?
13:19:50 <langdon> bkabrda, right.. i meant they all share the build-slice
13:20:35 <bkabrda> langdon: why exactly do we need to tell between these?
13:20:43 <bkabrda> *tell the difference
13:21:18 <langdon> bkabrda, because WG-wkstn may want to package httpd differently than WG-server?
13:21:37 <langdon> package isnt quite the right word
13:21:50 <juhp_> hmm, then it starts to get a scary for me :)
13:21:57 <juhp_> ah
13:21:59 <bkabrda> langdon: huh, that sounds crazy... although I can imagine them shipping different configuration files or something
13:22:01 <langdon> as in .. httpd in wkstn might be set up for dev.. but in server, set up for prod
13:22:44 <langdon> bkabrda, yeah.. i actually think envs and stacks should propose a way for a pakage to notice what "flavor" it is on and configure itself differently.. or some such
13:23:14 <juhp_> interesting
13:23:31 <langdon> so not sure where that happens.. is it one package that does different things? or different packages? e.g. right now we have httpd and httpd-devel .. but this would be like httpd-dev and httpd-prod
13:23:50 <langdon> but .. that seems like overhead that may not be necessary
13:23:51 <bkabrda> langdon: I think different packages with configuration files make sense... I talked about that with vpavlin once, but it seems that idea has been put to sleep
13:23:59 <langdon> brb
13:24:58 <juhp_> but maybe such config could be done with separate config packages?
13:25:20 <bkabrda> juhp_: that's what I was trying to suggest :)
13:25:25 <juhp_> ok
13:25:34 <juhp_> yes
13:28:11 <juhp_> I feel we made some progress today on understanding the rings better
13:28:46 * hhorak still picking up the most interesting thoughts for minutes
13:29:32 <juhp_> :)
13:30:01 <bkabrda> yeah, I do think we made some nice progress about it
13:31:04 * langdon back
13:31:21 <hhorak> #idea definition of ring 1 is a minimal set of packages that give you a functional system, with some sort of approval
13:31:21 <hhorak> #idea ring 1 should be self-hosted -- because you want to build very solid important packages using very solid important packages
13:31:21 <hhorak> #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
13:32:31 <hhorak> #idea then ring 2 includes clean/good pkgs of other stuff; ring 3 good pkgs but not complete; ring 4 any old stuff
13:34:04 * hhorak not sure now if we somehow agreed that ring 0 - 2 are rpm packages in koji, while ring 3 and 4 are rpm packages from copr and other non-rpm stacks ... is that something we're set on?
13:34:44 <bkabrda> hhorak: I think everyone agreed sort of implicitly, but maybe that's not absolutely necessary and can be decided later?
13:35:13 <juhp_> yea
13:36:33 <hhorak> bkabrda: probably can. So I think we've still some particular tasks for the next meeting (since we're quite a bit out of time :) ) so any topics already on our minds for the next meeting or (maybe better) for opening on the ML?
13:37:19 * hhorak thinks we need to set some technical expectations about how to differ ring 0, 1, 2..
13:37:57 <juhp_> yes
13:39:18 <hhorak> then I expect we need to look more closely on users' wokflow -- say he wants to develop or use some app from ring X -- what it actually means in practice..
13:39:46 <juhp_> good point
13:40:44 <hhorak> #idea topic for ML or some of the next meetings: setting some technical expectations about how to differ ring 0, 1, 2..
13:40:44 <hhorak> #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..
13:42:08 <hhorak> A bit marketing for the end --- the nomination period for Env & Stacks is open now, invite friends and nominate yourself!!!
13:43:10 <juhp_> good to know
13:43:39 <hhorak> it seems to me like we're fine with ending the meeting, so unless somebody stops me in a minute or so I'll send a farewell ..
13:44:09 <juhp_> thanks hhorak
13:44:59 <hhorak> Thanks for you, guys too!
13:45:30 <hhorak> #endmeeting