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