16:00:26 #startmeeting Server Working Group Weekly Meeting (2015-11-03) 16:00:26 Meeting started Tue Nov 3 16:00:26 2015 UTC. The chair is mhayden. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:26 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:37 #chair sgallagh mizmo nirik stefw adamw simo danofsatx mhayden jds2001 16:00:37 Current chairs: adamw danofsatx jds2001 mhayden mizmo nirik sgallagh simo stefw 16:00:39 .hello stefw 16:00:39 #topic roll call 16:00:40 stefw: stefw 'Stef Walter' 16:00:50 .hello jstanley 16:00:51 jds2001: jstanley 'Jon Stanley' 16:01:05 .hello duffy 16:01:06 mizmo: duffy 'Máirín Duffy' 16:01:08 .hello simo 16:01:09 simo: simo 'Simo Sorce' 16:01:15 .hello mhayden 16:01:16 mhayden: mhayden 'Major Hayden' 16:01:29 ahoy 16:01:31 .hello adamwill 16:01:32 adamw: adamwill 'Adam Williamson' 16:01:55 .hello kevin 16:01:56 nirik: kevin 'Kevin Fenzi' 16:02:07 (here, but also watching release stuff so likely distracted) 16:02:29 * mhayden is in two irc meetings but will try his best ;) 16:03:13 do we actually have an agenda today? 16:03:36 i didn't get anything back from my email 16:03:42 not much of one. ;) 16:03:47 meeting time perhaps? 16:03:59 did we want to line up this meeting with UTC or keep it lined up with the Eastern time zone? 16:04:14 #topic agenda 16:04:31 #info Agenda Item: Should the meeting time track UTC or EST? 16:04:58 I think we should stick to the same time UTC always. 16:04:58 vote: EST. The rest of my schedule tracks EST :D 16:05:28 10AM is somewhat difficult for me, 11AM works well. 16:05:41 yeah, we follow NA time for the qa meetings and it works... 16:05:56 i'm probably the odd one out 16:06:01 and poor adamw would have a 7AM meeting if we tracked UTC. 16:06:02 someone did make a good point that the vast majority of members are in north america 16:06:04 so i'll just bail if the earlier time doesn't work for me 16:06:38 jds2001: that too :) 16:06:41 stefw: does your locale observe Daylight Saving Time? 16:06:45 yup 16:07:01 CET 16:07:03 and CEST 16:07:12 then if we stick with Eastern time, the meeting *should* always stay at the same local time for each of us, right? 16:07:18 * mhayden is awful with time zones 16:07:23 not really 16:07:27 because everyone changes at different times 16:07:27 we still have a discussion gopign on the list over release criteria for cockpit 16:07:28 mhayden: i think CEST is a little off 16:07:29 but it doesn't really matter 16:07:39 hah okay 16:07:47 should we vote on this and then move to the cockpit discussion? 16:08:24 I see sgallagh still trying to push people to have proprietary products to test stuff to which I am opposed to formalize (not that I will not welcome volunteers test stuff, just not ok as a release criteria for Fedora IMO) 16:08:50 * jds2001 has said propietary products - at least Windows. 16:08:51 if we move an hour forward i can't eat lunch hehe 16:09:00 stefw: what's upstream take on those OSs/Browsers support ? 16:09:08 http://cockpit-project.org/running.html 16:09:09 and it would be very difficult for west coast folks to participate 16:09:18 simo, but we don't test them all at present 16:09:22 especially not in an automated fashion 16:09:25 i think we need to support other OSes / browsers (within reason) bc we're trying to bring those folks to our side :) 16:09:26 we'll get there eventually 16:10:01 mizmo: I am fine if upstream supports other stuff 16:10:20 I am not thrilled about making it a Fedora release criteria 16:10:30 * nirik is with simo here. 16:10:32 * jds2001 can spin up a windows vm and click around cockpit. I actually *have* an MSDN Operating Systems subscription from back in the day when I was doing a ton of install/dual boot testing. 16:10:43 * mizmo isnt sure about release criteria either 16:10:45 and i keep paying MS for some reason :) 16:10:51 I mean what if it's a IE or chrome bug and they won't fix it quickly for us... 16:10:51 because iof we go there then I would want also to see things like konqueror and epiphany there 16:10:54 * mhayden tables the time adjustment in favor of this cockpit discussion :) 16:11:00 which are you know, actually free and *in* fedora 16:11:01 * jds2001 is not for it being a release criteria, however I can test it 16:11:10 #info Agenda Item: Cockpit release criteria 16:11:45 mhayden: thanks 16:11:52 Note, at the present time Cockpit does no automated testing on anything but phantomjs (which is Webkit based) 16:12:11 Release criteria from Fedora would probably (should probably) spur us to do automated testing on real browsers 16:12:33 The Cockpit upstream folks will not sign up for manual testing :) 16:12:36 stefw: do you have any infrastructure for that ? 16:12:40 stefw: if something doesnt reneder properly in a browser, is it a browser bug or a bug in what is being rendered? 16:12:53 we have lots of integration tests where we bring up thousands of VMs per day to test Cockpit 16:13:09 I think that some of those VMs could be selenium based, and bring up real browsers 16:13:17 and perform certain limited tests using real browsers (not everything) 16:13:19 jds2001: given how our W3C specification are so awesomely specified, the answer is a fat "it depends" 16:13:23 stefw: i dont blame you for not signing up for manual testing. 16:14:05 stefw: does selenium also test what the browser show ? (screenshot based or something ?) 16:14:10 So what follows is that if we do automated testing, some of that automated testing can likely happen against proprietary browsers. 16:14:14 i would think tho in 2015 you're not going to have the crazy weird critical 'one browser is f*ed' bugs you used to have before all of the frameworks we have now 16:14:22 simo, we don't do screenshot based testing, rather DOM based testing 16:14:25 and im assuming cockpit is using some standard frameworks with built in cross browser compat features 16:14:36 ie: "can i click this button, and see the resulting effects on the system" 16:14:38 when something fails 16:14:43 then we produce a screenshot of teh failure 16:14:45 for diagnosis 16:14:56 mizmo: we hit a bug in this cycle that chrome did not work 16:15:01 mizmo, well that's a non-sequitor 16:15:20 but we do make sure to only use browser features available on the browsers listed here 16:15:26 http://cockpit-project.org/running.html 16:15:47 but browsers are obviously different enough, that cockpit can be completely fall non-functional in a given browser 16:15:51 so we really need to test that 16:16:00 So I guess the question becomes: 16:16:27 What browsers should Fedora manually validate against for its release criteria. 16:16:35 If upstream does validate against a broader set of browsers 16:16:45 i'm not totally sure about that 16:16:46 it is my opinion that Fedora has the leeway of doing any manual testing against a more limited set. 16:16:58 stefw, it's a non sequitur to assume cockpit is using standard cross compat frameworks? or is it a non sequitur to assume cross compatibility issues aren't going to be as troublesome as they used to be quite some time ago bc of said frameworks? 16:17:11 the criteria and the validation tests are obviously strongly related, but they don't have to be in lockstep 16:17:13 "standard cross compat frameworks" is a non-sequitor :P 16:17:19 we have several criteria already which we don't exactly fully test 16:17:35 stefw, you're not using jquery or something like bootstrap or less / sass / whatever 16:17:37 adamw: how do we know if we violate them? 16:17:37 ? 16:17:39 sorry, distracted - but I am here 16:17:44 the idea is, if someone doing casual testing comes across a violation of that criterion, we want to treat the bug as a blocker, but we recognize it's not possible to fully test them 16:17:59 jds2001: we don't, always. but then, we don't always know if we violate the criteria we do 'have' tests for, because no test is perfect. 16:18:19 mizmo, yes, most of the above (and angular, patternfly, etc.) ... but use of them does not guarantee cross compatibility with browsers 16:18:37 stefw, oh of course not but it's different than the days of hand-maintained js / etc 16:18:38 adamw, interesting ... that does reframe the issue 16:19:15 mizmo, well there's lots of hand maintained JS in cockpit ... as there is in any non-trivial browser based application 16:19:27 stefw, im just going to drop it, this is unhelpful 16:19:31 but obviously we don't reinvent everything, and use jquery, angular, and other stuff whereh appropriate 16:19:35 this is actually a relatively tractable issue as these things go, but it's still *possible* for us to say 'we'll block on cockpit being broken with sufficiently popular browser stacks if we notice it' 16:19:44 stefw: so you would catch if the browser doesn't do the action you want, but you'd not catch things like "all buttons are technically there but I can't see jack of the UI" 16:20:07 simo, the testing infrastructure checks that buttons are visible before it can click them 16:20:15 stefw: how ? 16:20:26 by checking their size in the phantomjs browser 16:20:37 adamw: i think that's a good compromise - it doesnt *require* us to test anything but if someone is so inclined, then we'll block. 16:20:41 but obviously there are some issues that may not be caught 16:20:44 there always is with testing 16:21:09 adamw, yes, i would be for that ... adding to the criteria ... but not requiring manual testing by Fedora 16:21:10 do we define different tiers of browser support then, these browsers are tested, these ones are not but if something is found we block, these ones are not and if something is found we dont care 16:21:28 mizmo, i think that makes sense 16:21:41 mizmo: that would be the real-world situation, i dunno whether it'd be necessary to advertise it. 16:22:04 adamw, well id think you'd have to define the first two 16:22:16 the question is more complex than just the browser, too - this very bug involved TLS libraries 16:22:22 mizmo: sure 16:22:53 imagine a situation where you can access Cockpit with Firefox 43 on Fedora 23 but not with Firefox 43 on RHEL 7, or something like that 16:22:54 if I tested with MyGreatBrowser and it broke, I dont think we'd block 16:23:00 yes 16:23:01 it fails the test of popularity 16:23:05 s/MyGreatBrowser/epiphany/ 16:23:19 which doesn't work at present, by the way ^^ 16:23:20 but what about firefox on mac is broken, firefox on fedora just peachy 16:23:22 due to SSL + WebSocket issues 16:23:35 so i think we'd have to stick a 'sufficiently commonly used' or similarly wording in the criterion and leave it up to subjective evaluation when we hit issues 16:23:47 mizmo: right, that's my point - there are a lot of possible combinations 16:23:55 indeed 16:23:57 then the question becomes 16:24:01 how can someone unblock Fedora 16:24:09 if they do not have access to the given platform 16:24:27 i, for example, would be unable to help unblock a Fedora release, if it was blocking on a Mac OS + Firefox + Cockpit issue 16:24:49 well, it just becomes another remote debugging scenario, i guess. we deal with 'em in various contexts. you need to puppet whoever has access to the platform to figure out what's going on, make some inspired guesses, blahblah 16:24:58 fair enough 16:25:02 but yeah, it's a worry 16:25:22 apparently safari is at 3-4% of users, chrome is ~65% and firefox ~21% cross platform 16:25:31 IE ~6-8% 16:25:32 we do more or less have a precedent that a blocker we literally do not have the ability to fix becomes notablocker though (it's somewhat fuzzy and we should write it down better) 16:25:54 it's kind of an inevitable consequence of the idea that we don't have a time-based or quality-based release process, but a hybrid 16:25:58 so it might not be the browser itself that would make sense to be flexible on, but hte platform its running on (between ff and chrome) 16:26:10 mizmo, that's an interesting idea 16:26:10 that inherently means that none of the quality requirements can be entirely absolute 16:26:14 in fact i was just about to suggest it 16:26:22 one of the principles of Cockpit, is that we expect a lot from the client 16:26:27 and minimal footprint on the sherver 16:26:39 that is, one might be required to use a different (modern) browser on the client 16:26:46 i've been assuming all along that we're only blocking on things which are fairly clearly the server end's fault 16:26:53 the one stat where safari jumps is on ipads, 60% share 16:27:06 yes, but if remain accessible to each platform the users are using 16:27:09 rather than each browser 16:27:15 does anyone *use* cockpit on an ipad? 16:27:15 that may be a good enough compromise 16:27:19 do we care about cockpit being usable on a tablet 16:27:35 like if someone couldn't log in using chrome on android on their samsung galaxy whatever tablet 16:27:39 we do care about it, just not as much as laptops 16:27:55 we do consider that during design and so on, but don't test it sufficiently (yet?) 16:28:01 but again, this is about Fedora Server 16:28:04 adamw, can we manually test using chrome or is that no good bc it's not Free 16:28:26 mizmo: sure we can, there's no ban on testing non-free stuff. 16:28:33 heck, we have 'multiboot with windows' in the release criteria. 16:28:40 bc ideally i would think maybe chrome (65% usage) and firefox (20%) would be manually tested on fedora 16:28:42 tier 1 16:28:43 i think the concern was perhaps it was wrong to *require* someone to test a non-free thing. 16:28:50 then tier 2 (not manually tested but could be blockers) 16:29:11 would be chrome and firefox on os x / windows (have to define version numbers of each, we shouldnt care about os x tiger or win 95) 16:29:36 and tablets + everything else would go under tier 3, the don't care tier 16:29:51 or you could promote specific tablet+browser combos to tier 2 if you wanted to get more into that 16:30:12 i dont know that server admins are the type to really want to manage stuff on a tablet - just dont know 16:30:40 (the stats i got, btw, are from w3c) 16:30:48 aren't there some third party services that can do some of this testing for us, even on non-free platforms? 16:31:10 mhayden, yup ... i would think any automated testing should happen upstream 16:31:18 100% agree 16:31:21 sure, but then it's double whammy... non free service testing non free thing. ;) 16:31:30 as adamw this is about whether Fedora blocks when a bug is found, not how the bugs are found, and how testing is done 16:32:31 Cockpit, a Fedora Server product, works fine with Fedora packaged browsers. Why are we even discussing blocking on something we can't control? 16:32:48 that is in fact what we're discussing 16:32:56 on the presupposition that the bug is in Fedora 16:32:59 danofsatx: because we don't live in spherical cow land where people all use fedora. 16:33:00 danofsatx, we can control the issue if the bug is in cockpit 16:33:13 but yeah, as i said above, this is all more or less assuming the bug is on the fedora end. 16:33:46 (note that it would've been fairly likely this borkage would've showed up with later Firefox versions, i'm guessing.) 16:33:47 Testing is a defined environment. When you open the environment to external inputs, you loose control of the testing environment. 16:33:53 from my "enterprise" hat, it's *very* important that it work using Windows. 16:34:12 jds2001, do you think IE is critical or chrome and ff on windows good enough? 16:34:21 chrome and ff is good enough 16:34:24 +1 16:34:40 IE is our default browser at $DAYJOB, but we *can* use the other two. 16:34:49 jds2001: condolences 16:34:56 jds2001, was that the case at pervious $DAYJOBS ? 16:34:59 previous 16:35:03 simo: i mostly use chrome :D 16:35:07 soon you'll have Edge (or whatever new name MS come sup with) 16:35:11 mizmo: yeah 16:35:22 chrome/ff are standard at $DAYJOB here 16:35:30 on windows/mac/linux, of course 16:35:42 i think we may be reaching the point where we're not getting anything further from irc discussion 16:35:57 i'd suggest the next step would be for someone to draft a criterion 16:36:45 * danofsatx is still looking for a $DAYJOB. Anybody have one handy? 16:38:56 adamw, would they only apply to the cockpit criteria that are already in place 16:39:06 yeah, i'd figure so. 16:39:20 so it'd just be an additional line on the cockpit ones already there 16:39:25 i can draft something 16:39:34 does it have to take into account alpha / beta / final or is it meant to be final? 16:42:12 * mizmo taps mic 16:43:07 that sounds good to me ... don't the same alpha / beta /final apply from the current cockpit criteria? 16:43:36 mm, i think it probably makes sense to put this at final 16:44:22 +1 16:44:24 okie doke 16:44:34 i can draft something up and send to list, will note it as a final criteria 16:44:38 criterion 16:44:39 i guess 16:44:48 that'd be great 16:45:12 #action mizmo to send a draft of final criteria to the list 16:46:47 how about the meeting time thing 16:47:59 it sounds like there are two options: 1) keep tracking Eastern time (as it is now) or 2) track UTC time 16:48:10 votes for #` 16:48:13 er #1 16:48:21 #1 16:48:22 tracking UTC time would mean the meeting would shift back/forth with DST 16:48:37 * nirik prefers 2, but is used to being outvoted. ;) 16:48:40 #1 for me 16:49:42 I like sticking with NA Time. (some) European times shift also, but within (I think) 3 weeks of the NA shift, so there would be breif periods of confusion for CET/CEST members. 16:50:00 so 4 for #1, 1 for #2? 16:50:25 sounds like we can leave the timing as it is for now and have a more detailed discussion on the list if needed 16:50:46 NA and Eruope are the only two continents I know anything about the time zones on, however.... 16:51:42 #info Keep meeting at 11AM Eastern Time for now 16:51:44 * jds2001 is for #1 personally 16:51:51 #topic Open Floor 16:51:58 anything else to discuss? 16:52:06 there was that cloud sig <=> server sig discussion 16:52:12 which kind of went off on a cloud-init tangent 16:52:14 F23 is working great on various servers/VM's i'm running -- so kudos to everyone there 16:52:18 about collaboration between the 2 groups 16:52:26 ah yeah 16:52:36 would it make sense to have a joint meeting and lay out the current issues? 16:53:35 i think so 16:54:34 looks like we got testing for the freeipa and pki-core updates for f23, which is great 16:55:42 #action Figure out a way to have a joint meeting between Server/Cloud groups 16:55:54 we should assign that to sgallagh since he's not present 16:55:57 :) 16:56:34 * mhayden needs to scurry across the building for a talk 16:56:40 anything else to discuss? 16:57:06 * mizmo not i 16:57:42 alrighty, i'll close it up 16:57:50 thanks to everyone! :) 16:57:52 #endmeeting