12:01:10 #startmeeting Env and Stacks (2015-01-14) 12:01:10 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 12:01:16 #meetingname env-and-stacks 12:01:16 The meeting name has been set to 'env-and-stacks' 12:01:24 hi! 12:01:32 #chair pkovar tjanez samkottler bkabrda hhorak juhp ncoghlan vpavlin sicampbell 12:01:32 Current chairs: bkabrda hhorak juhp ncoghlan pkovar samkottler sicampbell tjanez vpavlin 12:01:44 #topic hello-ing 12:01:54 hi guys 12:01:57 Hi 12:02:11 Hi 12:03:21 #topic Fedora Rings 12:04:37 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 For start let's refresh the original idea: 12:05:39 #link http://mattdm.org/fedora/next/#15 12:05:40 #link http://mattdm.org/fedora/next/#20 12:08:09 * langdon lurks and can only stay about 30 mins 12:08:24 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 hi! 12:08:43 langdon: good morning, kind of hoping you can kick it off a bit :) 12:08:47 sorry to be late 12:10:09 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 as a result, I htink it is tough to make a call about something like scl 12:10:37 true 12:10:38 and user's way to use the rings.. 12:10:53 langdon: that's my feeling as well. 12:10:58 which ring does scl live in? (not really asking, just pointing out it is hard to answer) 12:11:37 hhorak, also, user's why [sic] to use the rings 12:12:39 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 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 bkabrda, I agree 12:14:27 what I'm trying to say is that defined like this, ring 2 has a too wide definition 12:14:32 bkabrda, so.. is it a property of ring2 that it must support diff versions of things? 12:15:05 langdon: not sure I understand the question 12:15:14 * bkabrda needs more coffee 12:15:40 well.. in your first stmt you said you need more than one version of py in ring2 12:16:04 langdon: ah, I see, let me rephrase that 12:17:18 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 so these minimal stack should be kept in ring 2, while other (possibly parallel) stacks should be moved to ring 3 12:18:08 ring 3, in my mind, is a goto place for people who are not satisfied with the system version 12:18:13 #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 bkabrda, ok so what is the diff between r0 / r1 and r2 for this? 12:18:17 #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 like why is py not in r1? 12:18:48 * langdon plays devils advocate 12:18:59 langdon: my perception of rings is 12:19:16 ring 0 - the minimal set of packages to boot a system 12:19:31 (like the atomic or so) 12:20:02 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 r1 needs to be self-hosting 12:20:39 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 juhp_: r1 or r0? 12:20:47 r1 12:20:58 r0 is not self-hosting - too small 12:21:38 that's my perception of the concept 12:22:15 bkabrda, so iiuc correctly your python package would live in r1 (or r0 even?) but pythonXY would like in r2? 12:22:25 like = live 12:22:53 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 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 my interpretation is that r2 is more or less for scl like packages 12:24:45 bkabrda, okay, I meant so pythonXY not all :) 12:24:48 some! 12:25:18 bkabrda, or what would you put in r2? 12:25:38 juhp_: as I've said, copr/playground, upstream repo mirrors (devpi) etc 12:26:00 * juhp_ re-reads 12:26:27 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 bkabrda, okay sorry - then I don't understand what separates your r1 and r2 12:27:17 bkabrda: unless somebody is not hitting on anybody else we're fine 12:27:22 bkabrda, how can python not be a part of r1? 12:27:34 juhp_: the system python would certainly be part of r1 12:27:35 bkabrda, hinting at? (roughly, suggesting but leading) 12:27:41 ok 12:27:43 * langdon hits the keyboard 12:27:45 langdon: ok, scratch that :) 12:28:23 I guess the problem of my concept is not giving a clear distinction between content of rings 1 and 2 12:28:53 well.. i think bkabrda is doing a nice job of pointing out why the rings need definitions :) 12:29:26 langdon: :) 12:29:26 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 bkabrda, I think I got confused by "so these minimal stack should be kept in ring 2" 12:29:41 so why don't we start defining the rings together from number 0? 12:30:00 bkabrda: actually I don't see that as a problem, more as an implementation detail 12:31:02 hhorak: what were you replying to exactly? 12:31:23 I think ring 0 is just base/core - basically the domain of the Base WG 12:32:27 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 juhp_ +1 12:32:50 yeah, so as I've said, let's start defining from the bottom 12:33:11 juhp_: +1. to provide additional definitio, I'd call it a minimal bootable system 12:33:37 #info ring 0 is a minimal bootable system - basically the domain of the Base WG 12:34:08 ok, so that was easy :) I guess ring 1 will be more tough than that 12:35:01 (no dnf/yum?:) 12:35:22 anyway I think we can move to ring 1, yes 12:36:00 juhp_: I think dnf/yum isn't necessary in ring 0 12:36:30 bkabrda, it is in @core at least 12:37:28 ring 1 should include some basic libraries, tools, etc. for: upper ring and imho also for the minimal install of products.. 12:37:29 maybe an interesting question is what can be moved out of ring 1 to ring 2? 12:37:44 juhp_, +1 12:38:36 juhp_: yeah, I see the problem. given user application X (say somenone packages askbot), should it go to 1 or 2? 12:38:37 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 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 hhorak, yeah that may be good 12:40:13 #idea question is what can be moved out of ring 1 to ring 2? 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 12:41:55 hhorak, but maybe we need to work what they are first :) 12:42:52 juhp_: sure :) 12:43:40 it is kind of tricky though 12:43:44 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 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 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 juhp_: that is a good question. I still think that the most important question is "what packages go into ring 1?" 12:45:21 well my thinking was that ring 2 is the stacks-ring for stack that are not needed for ring 1 itself 12:45:53 bkabrda, ok 12:46:26 "needs to BR X" - I think BuildRequires shouldn't be reason to pull pkg from higher ring to lower.. 12:47:33 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 right 12:50:10 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 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 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 vpavlin: that's exactly what I was trying to say, yes :) 12:52:48 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 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 bkabrda, right maybe we can't :) 12:54:33 unless there are some objective criteria 12:57:00 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 langdon, any more thoughts on ring 1? 12:59:56 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 good question 13:00:57 vpavlin: but that also means that people can (and will) package pretty much antyhing into Fedora -> ring 1 13:01:33 so there's pretty much no distinction between ring 1 and 2 except where the packages are built 13:01:47 vpavlin: that would mean we're fine with the current status, but are we? 13:02:20 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 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 vpavlin, +1 .. isnt that the fpc? 13:03:27 langdon: is it?:) 13:03:48 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 yeah 13:04:22 So what about WGs specifying content of ring1 - f.e. Server should be able to do that WRT roles 13:04:32 And then ring2 would be the rest 13:04:39 i also think one needs to consider does r0+r1 = wkstn + r3-workstation? vs r0+r1 = server + r3-server?? 13:04:52 vpavlin, that might make sense yes 13:05:22 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 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 I think r3 would be optional stuff? 13:06:13 bkabrda, guidelines on pkg, fesco approval (or someone)... like r1 should be locked down .. not sure about r2 13:06:22 bkabrda: How? content of rings being defined by WGs - you would have to ask for adition 13:06:52 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 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 we could say ring 1 is default Cloud + default Server + default WS perhaps 13:07:52 vpavlin, yes 13:08:08 though also a bit scary 13:08:08 * langdon realizes in the example above he meant r2-wkstation and r2-server 13:08:13 bkabrda: I think the definition is always minimal set of packages that gives you functional system 13:08:14 ok 13:08:42 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 bkabrda: Definitely 13:09:01 e.g. from a WG that works on that product 13:09:03 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 r0 is Base WG product - minimal installable Fedora (Docker Base image + kernel?) 13:09:44 r1 seems the hardest to define 13:09:51 r1 could be minimal for product 13:09:56 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 r2 the rest in Koji 13:10:06 r3 copr + "stuf" 13:10:16 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 vpavlin, yeah I was also kind of thinking something like that 13:10:37 * vpavlin gets a bit of headache.. 13:10:37 bkabrda, i think r2 is still "koji" 13:11:00 * langdon runs rings around vpavlin's headache :) 13:11:21 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 assuming ring 3 is what vpavlin said - copr + "stuff" 13:11:38 bkabrda, I think so 13:11:47 bkabrda: r2 has to pass Fedora Review 13:11:52 bkabrda, yeah.. no bundling unless scl (or scl-like)? 13:11:55 I think I'm starting to like that 13:12:14 langdon, bundling means? 13:12:26 vpavlin, is "fedora review" current review? or some lighter set of guidelines? 13:12:34 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 langdon: I would see it as current review 13:13:10 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 We should still provide certain level of quality in Fedora...the low-quality-level stuff can go to r3, right?:-) 13:13:21 bkabrda, +1 13:13:23 langdon, ah right 13:13:39 copy libs etc, okay 13:13:59 vpavlin, +1 13:14:33 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 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 langdon: I think we want people to get to r2, since r1 is supposed to be minimal, but otherwise I agree 13:15:25 yeah r3 is kind of an incubator or experimental repo for fedora 13:15:28 r3 having some lightweight (prefferably automated) review 13:15:30 vpavlin, aha 13:16:02 juhp_ I think both our statement works fine 13:16:03 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 r4 does have license review though 13:16:31 langdon: where did r4 come from? :) 13:16:46 bkabrda, i like rings?! :) 13:16:47 bkabrda: From me....but I said - in the future:) 13:16:57 langdon: also, I'd add r1 is self-hosted 13:17:09 at least I think it should be 13:17:10 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 langdon: because you want to build very solid important packages using very solid important packages ;) 13:17:53 bkabrda, I think it should be yes 13:18:09 e.g. packages that build highly important stuff should also be considered highly important 13:18:13 vpavlin, cya 13:18:19 s/e.g./in other words/ 13:18:35 langdon: makes sense? 13:18:44 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 i guess i don't want a WG picking up a build pkg on the cheap.. :) 13:19:17 aha 13:19:36 langdon: I'm not sure about slices. what about packages that are used by two or more? 13:19:50 bkabrda, right.. i meant they all share the build-slice 13:20:35 langdon: why exactly do we need to tell between these? 13:20:43 *tell the difference 13:21:18 bkabrda, because WG-wkstn may want to package httpd differently than WG-server? 13:21:37 package isnt quite the right word 13:21:50 hmm, then it starts to get a scary for me :) 13:21:57 ah 13:21:59 langdon: huh, that sounds crazy... although I can imagine them shipping different configuration files or something 13:22:01 as in .. httpd in wkstn might be set up for dev.. but in server, set up for prod 13:22:44 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 interesting 13:23:31 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 but .. that seems like overhead that may not be necessary 13:23:51 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 brb 13:24:58 but maybe such config could be done with separate config packages? 13:25:20 juhp_: that's what I was trying to suggest :) 13:25:25 ok 13:25:34 yes 13:28:11 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 :) 13:30:01 yeah, I do think we made some nice progress about it 13:31:04 * langdon back 13:31:21 #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 #idea ring 1 should be self-hosted -- because you want to build very solid important packages using very solid important packages 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 13:32:31 #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 hhorak: I think everyone agreed sort of implicitly, but maybe that's not absolutely necessary and can be decided later? 13:35:13 yea 13:36:33 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 yes 13:39:18 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 good point 13:40:44 #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 #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 A bit marketing for the end --- the nomination period for Env & Stacks is open now, invite friends and nominate yourself!!! 13:43:10 good to know 13:43:39 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 thanks hhorak 13:44:59 Thanks for you, guys too! 13:45:30 #endmeeting