14:02:23 #startmeeting Meeting 14:02:23 Meeting started Mon Jan 23 14:02:23 2017 UTC. The chair is mvollmer. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:02:23 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:02:23 The meeting name has been set to 'meeting' 14:02:33 .hello mvo 14:02:34 mvollmer: mvo 'Marius Vollmer' 14:02:37 .hello dperpeet 14:02:38 dperpeet: dperpeet 'None' 14:03:43 #topic Agenda 14:04:04 * the GitHub BUG label 14:04:09 * Network integration tests 14:07:45 anything else? 14:08:25 #topic the GitHub BUG label 14:08:51 we were discussing this last week on IRC 14:09:00 background: last week I tagged a PR with "bug" (old habit from systemd where we categorize PRs and issues) and was told not to 14:09:00 and the question is: do we still need the BUG label? 14:09:18 originally we had this for bugs in the issues 14:09:37 indeed, if we don't do that let's just remove them -- it's dead cheap to put back if we ever want it again, after all? 14:09:39 and we still quite a few https://github.com/cockpit-project/cockpit/issues?q=is%3Aopen+is%3Aissue+label%3Abug 14:10:05 but theoretically our issues should all be bugs 14:10:07 yeah, I don't pay attention to that label 14:10:17 dperpeet: you don't use issues for RFEs? 14:10:18 yeah, I agree that this label is a bit useless 14:10:39 we found that wishes don't age well 14:10:47 either it's on our trello roadmap 14:10:53 or someone wants to implement something 14:10:57 in systemd we use it for "bug" vs "RFE", and have additional label for the component (network, pid1, nspawn, etc) -- in cockpit this could be "storage", "kubernetes", etc. 14:11:12 component ones I would understand 14:11:14 just putting a wish out there with nobody to work on it usually doesn't lead to any progress 14:12:01 I mean, ideas are awesome 14:12:10 but we have more of those than we can implement 14:12:30 so either you start implementing something 14:12:35 or convince others to implement something 14:12:41 so, if RFE is frowned upon and we don't use it, then "bug" is useless too indeed 14:13:03 pitti, RFEs are very valuable 14:13:10 but they need to be in the right form 14:13:23 https://github.com/cockpit-project/cockpit/labels/enhancement 14:13:29 72 of them 14:13:36 yeah, this is for small stuff usually 14:13:41 that's a different discussion I think 14:14:21 ok, anybody against removing the "bug" label from github? 14:14:45 we have "knownissue" also 14:14:50 that's good to keep 14:14:52 let's rename it to "improvement-potential" :) 14:14:56 heh 14:15:07 . o { Lernchance } *cough* 14:15:14 ok, I'll delete it 14:15:16 end of topic :) 14:15:58 roger 14:16:08 #topic Network integration tests 14:16:39 so I refactored the tests and changed them at the same time, and also we have some changes pending to the actual code 14:16:55 and the tests are failing in new and exciting ways now 14:17:02 so I am looking at that 14:17:18 thanks for the refactor 14:17:24 but you're right, lots of changes at once :) 14:17:25 i might find some real bugs, hopefully 14:17:33 not soooo much 14:17:37 but maybe too much 14:18:02 so now it looks like we are getting wrong property values on d-bus 14:18:23 this might be NM specific, but in any case the events in JavaScript don't match the events on D-Bus 14:19:03 anyway, a typical failure is that the health check fails, or is ignored 14:19:18 that sounds bad 14:19:21 so if you see that, you might want to ignore it 14:19:57 I also see some spurious disconnections during manual testing, sometimes 14:20:34 I tried checking, but didn't go into depth: did you make sure that nothing runs in parallel now that requires the same fixed ip? 14:20:45 I am pretty sure 14:20:58 there isn't any fixed mac anymore in the tests 14:21:36 but some devices used to be on dead vlans, and now they are all on cockpit1 14:21:43 right 14:22:04 we can put the "switch of rp filter" hack back 14:22:11 I make a PR for that 14:22:22 and debug into the D-Bus property mystery 14:22:50 the symptom of that is that a new bond shows up as unmanaged in the cockpit ui 14:23:01 because we miss the change that sets Managed = true 14:23:21 but that happens only on rhel-7 in one of the PRs 14:23:25 interesting 14:23:33 so, this is just a heads up 14:24:01 let's hope I find some real bug... :-) 14:24:21 ok, I'll be looking forward to seeing all those tests reliably green :) 14:25:25 yeah 14:27:00 hey i'm around ... on the train ... working on my talk for devconf 14:27:07 eot. 14:30:03 #topic Other business 14:31:58 looks like we are done? 14:32:27 it appears so 14:32:53 alright 14:32:58 #endmeeting