20:05:49 #startmeeting server wg 20:05:49 Meeting started Tue Jun 27 20:05:49 2017 UTC. The chair is jds2001. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:05:49 Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:05:49 The meeting name has been set to 'server_wg' 20:05:52 #chair nirik sgallagh mhayden dperpeet smooge jds2001 vvaldez adamw mjwolf 20:05:52 Current chairs: adamw dperpeet jds2001 mhayden mjwolf nirik sgallagh smooge vvaldez 20:06:02 .hello adamwill 20:06:03 adamw: adamwill 'Adam Williamson' 20:06:05 #topic roll call 20:06:11 heya adamw 20:06:22 .hello dperpeet 20:06:22 * jds2001 didnt see anyone else volunteer to run this 20:06:22 dperpeet: dperpeet 'None' 20:06:25 .hello mjwolf 20:06:28 .hello mhayden 20:06:29 mjwolf: mjwolf 'Michael Wolf' 20:06:32 mhayden: mhayden 'Major Hayden' 20:07:04 I'm not really here, but i may be able to answer the occasional question if mentioned 20:08:07 im only aware of one topic for this meeting, which is the modularity change for f27 20:08:27 #topic Modularity in F27 Server 20:08:48 so as i exepcted, there's been some feedback on devel@ 20:09:10 seems most of it was that folks wanted to be able to install non-modularized things. 20:10:43 * nirik is sort of here. 20:11:18 .hello langdon 20:11:19 langdon: langdon 'Langdon White' 20:11:21 * jds2001 just went and checked his mail, I havent followed the thread for a few days because of things. 20:11:26 jds2001: is that not something we were expecting? 20:11:58 adamw: there was loose consensus in here last week that we consider that as a 'failure mode' 20:12:39 well .. part of it is conflating "install a single rpm from a module" vs "install an rpm from some random place" 20:12:43 adamw: if you wanted something 'more traditional' the Everything netinstall is there for you. 20:12:46 the first is fine .. the second not so cool 20:13:23 langdon: thanks for making that distinction, it's an important one that I missed. 20:14:41 so .. if i have httpd-module, i may not get mod_ssl as an rpm in the default install .. i can still install it.. i will just get the right one based on the httpd-module-stream .. however, if i install "gnome" which isn't a module .. it isn't gonna be pretty becuase it would be like installing f26-gnome on f22-fedora 20:14:41 adamw: i noted you had schedule concerns as well. 20:14:49 well, just the question, really 20:16:14 adamw, so .. i share your concern.. but, yes, the goal is to deliver everything for server by the current schedule.. if we don't have enough time, i propose we cut things.. but, thats a decision for later 20:16:34 later == cut vs change schedule 20:16:49 and i think server-wg also agreed to that plan at the last meeting 20:16:58 i'm...deeply sceptical that we're going to be able to get all those interlocking bits done in time. with my Debbie Downer QA Person hat on. 20:17:11 sorry if i'm repeating stuff, i haven't been strictly keeping up lately :( 20:17:20 (just moved house) 20:17:26 no worries.. 20:17:32 I am also mainly because I feel like we have many idea(s) of what modularity means 20:17:46 adamw, and i am sure that moving went all to schedule too :) 20:18:10 * nirik thinks we are only going to find and fix some of the sharp edges by getting cut. ;) 20:18:35 nirik++ 20:18:35 jds2001: Karma for kevin changed to 46 (for the f25 release cycle): https://badges.fedoraproject.org/tags/cookie/any 20:18:58 smooge: for me it's mainly the fact that changes seem to be needed in the compose process, bodhi, koji etc. 20:19:09 in my experience getting all those changes lined up always takes longer than people expect 20:19:25 agreed 20:19:26 nirik: yeah, i'm just wondering if we should be budgeting in more time to apply the band-aids ;) 20:19:35 so i guess the question is where are we on each of those? 20:20:20 * adamw notes his job in this group could probably be replaced by a robot programmed to say "that's going to be broken at first and take longer than you think to fix" at random intervals 20:21:43 well, there's already modular pungi composes... (not sure how usable they are tho) 20:22:00 bodhi is mostly set, but needs pungi to do the composing for updates 20:22:14 koji is pretty set, modules are building, etc 20:22:23 hmm, okay, that sounds quite promising 20:23:00 not to say there isn't a ton of work still to do. 20:23:53 adamw, yeah.. most of that work is falling on ralph and team.. they have a schedule that they are mostly on track for.. you know, except, bugs 20:24:10 im worried more about putting the module wrappers around things 20:24:34 and that last bits/details on composing which is harder than expected.. 20:24:58 but your major concerns are exactly why we did boltron.. to try to get 90% of the way there before it mattered 20:25:16 but boltron isn't out yet (~2 weeks yet) .. so .. 20:25:21 we still have some kinks 20:25:25 my main worry at the moment is how this will be laid out on the mirrors? 20:25:50 smooge: you're concerned about the space? 20:25:57 smooge, threebean's plan was flattened in to directories.. what we have been calling "virtual repos" .. 20:25:59 both space and layout 20:26:21 so . instead of a "repo per module" .. it is ~1 repo and the modules are identified by the metadata and dnf 20:26:38 and how updates are put out for mirrors to get 20:26:44 so that the mirrors don't really see anything different 20:27:22 the update would be to the "server repo" as it is today .. and would mirror the same way .. but that part is still a bit in flux .. updates were for after boltron 20:27:32 as I would like to make sure mirrors are aware of any changes before hand as many of them have special scripts to manager their local layout 20:28:02 smooge, i think we share your concern.. hence this design .. but.. ralph could answer better than i can 20:28:19 or nirik ... i am just not sure how close you are to this bit nirik 20:28:53 not sure, but I think it's just more repos of rpms... so we should be able to handle that 20:32:32 glad i could allay all your concerns.. i can take the rest of the day off now, right?!?! ;) 20:33:00 langdon: go home and have a beer :D 20:33:05 jds2001, lol 20:33:31 * langdon has to transport kid to softball game.. 20:33:37 in a while 20:33:43 langdon: that's what your back yard catapult is for 20:33:44 ok, maybe the beer isnt such a hot idea :D 20:34:21 adamw, still in testing .. qa keeps saying "we are too busy testing the last version to get to it" 20:34:40 20:34:43 =) 20:35:01 speaking of which, we need acceptance criteria for this stuff :) 20:35:14 * adamw suddenly discovers he has something terribly important to do somewhere else 20:35:50 is someone working on that, or is that an open item? 20:36:12 jds2001, i should probably have a better idea what you mean.. but .. i got nothing.. 20:37:00 #link https://fedoraproject.org/wiki/Fedora_26_Alpha_Release_Criteria 20:37:01 my fedora slang is failing me 20:37:06 and similar for beta and final :) 20:37:10 that is what i thought.. ok 20:37:27 well 20:37:48 the release criteria are generally speaking functional, they talk about how the final product should behave 20:38:08 adamw: that will necessarily change, no? 20:38:29 we're probably going to need to change / add to them *somewhat*, but a lot of what's there will probably still be appropriate, and the release criteria may not be the appropriate mechanism to assess / define some of the work that's involved 20:38:35 sure, to some extent 20:38:37 this product is not only plumbed differently, the user visible behavior is different. 20:38:52 but i don't think the release criteria are necessarily the way to cover, for instance, 'are the bodhi changes in shape yet' 20:39:09 adamw: agreed 20:39:12 so aside from those, i notice that most of the Change proposals so far have no "How To Test" section, for instance 20:40:11 yeah.. i ran into that and i think we need to work through it.. in a sense it is the same question as jds2001 has.. 20:40:17 i'm not sure how well this is formulated, but i kinda have a high-level expectation that Change proposals should at least attempt to cover: i) how exactly do we decide that this change is 'done' to a sufficient degree, ii) what do we do if it all goes wrong (which is the 'Contingency Plan' section, which similarly appears to be missing) 20:40:47 adamw, i had a contingency plan.. and mine is the only one that actually hits anything 20:40:50 didn't i? 20:41:10 if host & plat don't ship, it just drops on the floor 20:41:27 and my contingency plan kicks in 20:41:32 I'm not sure it's efficient to spend too much time on contingency plans 20:41:38 because my deps aren't met 20:41:45 langdon: sorry, which change are you referring to here? 20:42:18 i don't see either 'how to test' or 'contingency plan' for: 'Modular Release', 'Host and Platform', or 'Modular Server' (unless i'm missing them) 20:42:22 so .. the modular server one (the one i wrote) ... is the only one that materially impacts the fedora release .. as in it is a modular server or it isn't 20:42:25 i hadn't got any further in the list yet 20:42:39 arggh .. did i drop it? 20:42:43 i stink at wiki 20:42:51 well, i'm reading the email, not the wiki 20:42:53 in short.. it is "deliver without modules" 20:42:59 so i guess either that, or jan missed it out of the email 20:43:20 and that should be triggered with any of the others failing 20:43:21 anyhow, i agree with dperpeet that the concepts may not necessarily be *entirely* applicable to something as big as this 20:43:45 but the higher-level idea that 'we need a way to decide how "done" it is' and 'we need a plan for what happens if it ain't done' are still i think valid 20:43:47 adamw, but a measure of success is essential 20:43:51 there is nothing in the changes that gates a traditional release .. we just are electing to do a modular release 20:44:13 adamw, +1 .. we need AC or release crit .. or test 20:44:27 langdon: well, the Modular Server change states: 20:44:28 "This change replaces the Fedora 26 Server release-blocking 20:44:28 deliverables with exactly the same things (DVDs and netinst images) 20:44:28 but delivered via Modularity instead of the traditional process." 20:44:34 i just couldn't figure out how to say "well.. all of fedora server needs to "work" in that format 20:44:49 " 20:44:57 format == change proposal 20:45:07 which sounds like we're not hedging our bets and *also* doing a traditional server release, it sounds like basically "for F27 Server is gonna be modular, end of story" 20:45:14 did I misread that? 20:45:26 adamw, that is correct.. we were talking about the contingency plan .. 20:45:29 adamw: thats the proposal. 20:45:29 ah, okay, i see 20:45:42 sorry, wasn't quite sure what you meant by "there is nothing in the changes that gates a traditional release" 20:45:48 so .. change = everything modular; fail = nothing is modular 20:45:56 ok I need to head out and pick up kid 20:46:00 sorry smooge 20:46:06 that seems plausible, sure. 20:46:11 smooge, one at a time.. don't hurt your back :) 20:46:28 he's bigger than me.. so maybe I should have him pick me up 20:46:40 but .. we don't have a great doc for "what is fail?" 20:46:44 smooge, lol 20:47:42 yeah, obviously the 'success definition' and 'contingency plan' bits kinda go together 20:47:45 langdon: i dont think we're going to accomplish everything that we want by f27, its ambitious. But we need to know what's "good enough" 20:48:00 and what causes us to hit the Big Red Button(TM) 20:48:10 jds2001, right .. which "test" in the change proposal didn't really seem to cover it 20:48:48 and /me thinks change proposals should be the beginning of the discussion more than the end of it .. but that's just me.. 20:49:00 oh for sure 20:49:08 i'm just pointing it out as something we need to figure out 20:49:12 so .. i think f-qa, modularity, and server need to get together and figure out how to document this.. 20:49:19 that's one of the reasons we do change proposals, for sure :) 20:49:21 adamw, ohh yeah.. no offense taken 20:49:37 i think we may possibly also want to involve some subset of fesco, if we can do it without being too unwieldy 20:49:51 i think the hardest thing will be how do i say "this is fail" .. i am pretty sure most of us "know" what we mean .. just not how to say it 20:50:00 as i suspect scheduling concerns may come up 20:50:01 i think the release-crit might be a good model 20:50:22 there are rules for the Change process already, but we've already kinda established that this is a bit of a 'special' situation 20:50:36 adamw, yeah.. hence my overview email :) 20:50:53 the rules in the Change process are kinda simple and implicitly assume that Changes are easy to 'drop out': the rule is if the Change isn't 'done' enough at various points, it gets dropped 20:50:59 "so there are these 52 moving parts that don't seem linked in anyway"... 20:51:12 that seems like it might be too inflexible here, so i'm suggesting maybe we might want to thing about potential situations ahead of time 20:51:33 like 'we get to Alpha freeze and we're not *quite* ready to deliver a modular Server Alpha but maybe we'd be able to do it in a week' 20:51:35 what do we do then? 20:52:23 right .. exactly .. but more importantly (for now at least) "what is the modular server alpha"? and how flexible is that definition? 20:52:51 wouldn't a more constructive way be to define a minimal set of features? 20:52:52 let me put it a little differently .. we need host, platform, shared-userspace but then everything else is kinda optional .. 20:53:01 but it wouldn;t be usable 20:53:27 kinda like fedora could ship with a kernel and glibc .. and, technically, it would be a release .. but not very usable 20:53:33 i guess we could start out with just the folks suggested and broaden out as necessary 20:54:13 langdon: well, it seems a bit more complex than that to me, there are various 'dimensions' to it...what if we can ship all the initial release bits but there's some kind of significant issue with the update process? stuff like that. 20:54:22 * adamw likes to complicate things! 20:54:51 adamw, ahh yes.. but, that is all in the infra.. we have those triggers already .. on the f-2 proposals (IIRC) 20:54:57 fair enough 20:55:40 this is more about "what is a legit fedora server" .. if that is built as modules and works .. \o/ 20:56:10 adamw, there are no release-crit for each edition, are there? 20:56:25 there are actually some server-specific criteria, yeah 20:56:42 oh i see them 20:56:46 https://fedoraproject.org/wiki/Fedora_26_Alpha_Release_Criteria#Server_Flavor_requirements 20:57:01 we may need to rejig the Role stuff for the new gen role implementation, but that's a separate topic i guess 20:57:07 so .. maybe this is the answer? maybe re-work this to be applicable for a modular-edition? 20:57:22 this == the release criteria 20:57:29 we can certainly cover some things with release criteria changes for sure 20:57:30 i am not even sure it is that different 20:57:46 but i suspect we may also want to come up with sorta 'mini criteria' for each change, to aid assessment of the changes' status 20:58:23 there's a sort of...thing...with the release criteria which i have in my head but have trouble formulating 20:58:48 adamw, yeah.. i think this only applies to "mine" .. the "modular server" .. the pieces that modular-server needs should or do i have their own "fail/pass" rules.. and are less complex to test, i believe 20:58:52 but my best attempt is...the release criteria *kind of* assume some sort of underlying stability in the really fundamental bits of the distro 20:59:33 otherwise there's a danger of trying to encode *everything* about building an OS into the release criteria and it'd just get (even more) unwieldy 20:59:42 adamw, well.. i think you mean.. you can fail well before you get to the first "test" .. which i agree with.. but it doesn't change the test 20:59:45 might be better to say "the project" than "the distro" there 21:00:02 yeah, but even beyond that, there are things that practically speaking we need to be working that we don't write into the criteria 21:00:36 as i said, i have trouble expressing what i mean here, but basically it comes down to: when we start making radical changes to really critical things, we may need mechanisms beyond the release criteria until they settle down 21:00:42 mechanisms and processes 21:00:59 which can sometimes boil down to 'let's all sit down and have a meeting and agree whether this stuff is even vaguely viable' (like we did with newUI, for instance) 21:01:11 like .. "installer must run" requires the installer to have a working knowledge of modules before it can even sorta be run.. but you don't need to add that to the test.. the installer still doesn't run :) 21:01:27 anyhoo, i sense this is kinda getting a bit bogged down 21:01:58 i think we agreed at least we should look into somehow defining ultimate 'success' / 'MVP' state for the changes, so that's a concrete thing to work on 21:02:00 adamw, ill have adamS setup a meeting to plan a meeting to talk about a larger meeting where we can hash this out 21:02:03 and revising the criteria, of course 21:02:36 * langdon kids .. he will jst schedule a meeting 21:03:34 * langdon points at the clock 21:03:57 ahh, the pitfalls of having a meeting that runs against beer o'clock 21:04:07 sorry adamw, not quite yet for you :D 21:04:13 it's always beer o clock. ;) 21:04:17 ...somewhere. 21:05:12 langdon: so i guess the action is to schedule another meeting to talk about success criteria? 21:05:57 jds2001, yeah.. i think so 21:06:22 #action langdon to schedule another meeting to talk about success criteria for modular-server 21:06:43 anything else? 21:07:09 ok... gotta run.. kid -> softball .. but znc will let me know if anything else happens 21:07:32 i think ending the meeting is the next thing that happens :D 21:07:39 unless anyone has objections to that? 21:08:10 I OBJ- no, wait, i don't. 21:08:59 #endmeeting