14:00:31 #startmeeting fedora-qadevel 14:00:31 Meeting started Mon Aug 7 14:00:31 2017 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:31 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:00:31 The meeting name has been set to 'fedora-qadevel' 14:00:36 #topic roll call 14:00:43 #chair kparal 14:00:43 Current chairs: kparal tflink 14:02:17 * kparal is here 14:03:37 #chair jskladan 14:03:37 Current chairs: jskladan kparal tflink 14:03:46 no lukas? 14:04:14 as if Lukas ever used irc... 14:04:29 * tflink shrugs 14:04:35 all the shorter of a meeting :) 14:04:42 #topic Announcements and Information 14:04:51 #info ci-listener is up and running in the CentOS CI Infra - tflink, pingou 14:05:00 he has to feed the rabbits, as usual 14:05:00 any other items? 14:05:09 convenient timing 14:05:17 right! 14:05:22 I'm starting to suspect something 14:05:27 I talked to him and have some info, at least 14:06:12 I'm certain I added something to the wiki earlier this day 14:06:20 you added it to agenda it seems 14:06:26 ah, my bad 14:06:27 so now we need to discuss it 14:06:30 :) 14:06:31 yay 14:06:40 sorry, though 14:07:00 #info Moved tickets from Phabricator to the respective repositories https://lists.fedoraproject.org/archives/list/qa-devel@lists.fedoraproject.org/thread/EEA7DJUICDMSCI4R7I54GBEKBMHDBU2X/ - jskladan, kparal 14:07:00 #info Archived differentila revisions' "html snapshots" and raw diffs. Accessible at https://fedorapeople.org/groups/qa/phabarchive/differentials/phab.qa.fedoraproject.org/ - jskladan, kparal 14:07:07 * tflink didn't see them at first 14:08:02 any comments/questions/additions? 14:08:04 * jskladan has nothing to add 14:08:17 nope 14:09:19 cool, moving on 14:09:24 #topic Phabricator Migration 14:09:44 other than the wiki, is everything moved off of phab? 14:10:19 Tickets and Diffs are 14:10:31 jskladan: what about the infra diff? 14:10:40 other than parts of the wiki, what is left? 14:10:55 kparal: there is no sensible way of moving it, IMO 14:11:07 just create a ticket and attach diff 14:11:13 or include it as a code block 14:11:19 no me gusta :) 14:11:31 jskladan: put the link here so that tflink knows what we're talking about 14:12:20 pff /me searches 14:12:31 #link https://phab.qa.fedoraproject.org/D1208 14:12:53 just so the context is complete - there is no _good_ way of doing stuff like this now 14:12:54 the point is, a PR can't be created from a file 14:13:00 yeah, I don't know of a good way to do that other than sending patches around 14:13:14 aka "PR for a repo, that is not on pagure, but we'd still like to discuss it" 14:13:29 review on ML 14:13:34 so just upload somewhere where you can show differences nicely, and link it in an issue 14:13:40 tflink: noooo 14:13:51 kparal: could we do it with all the pr's? 14:13:54 :) 14:14:06 jskladan: it would be consistent .... 14:14:14 tflink: +1 14:14:25 but I, for one, am lazy enough that a nice visual representation is appreciated 14:14:51 maybe pagure can highlight patches as code blocks? 14:14:57 we can try 14:15:27 if it can, I'll move the pagure's score from -1345.3 to -1345.2! :) 14:16:37 nope, it can't 14:17:16 #info for now, any patches on outside projects (i.e. infra) will have to be discussed as patches, either in tickets or on ML 14:17:40 * kparal objects to ML 14:18:08 also, we don't have a good way to run linter for our projects right now 14:18:14 I'll file a ticket about it 14:18:42 pagure CI or maybe travis ci is likely the most sane way forward 14:19:07 I don't want to wait on CI to find out I have a linter error 14:19:13 of course it's good to have something server-side 14:19:21 but I want to also have something client side 14:19:23 doit? 14:19:34 sure, somebody needs to implement it 14:19:53 on the diff only, not on the whole project. (I can run "flake8 .") 14:20:02 * tflink can put it on his todo list 14:20:20 yeah, that might take some work 14:20:34 can git do pre-commit check? 14:20:48 yes, that's one way. I already looked at it a bit 14:21:10 it just needs some testing and figuring out corner cases 14:21:18 like if you can override a pre-commit hook for example 14:21:21 I don't know yet 14:21:39 anyway, that was just a side-note 14:21:54 pre-commit hook would be nice, imo 14:22:09 although, I can see it becoming quite a pita fast 14:22:28 (or I'll just learn to write pep8 compatible code on the first try :)) 14:23:23 right, for WIP branches that might be annoying 14:23:25 how about autopep8 as post-push hook on server? 14:24:03 no likey 14:24:08 kparal: why not? 14:24:23 I don't want my code to be reformatted randomly 14:24:28 I for one do not see a reason against using autopep8 14:24:38 then it's fine 14:24:40 let's skip this discussion right now 14:24:41 it is not random :) 14:25:15 #info now that we don't have phab linting our code, we need to find a new way to have that check run 14:26:11 #link https://pagure.io/taskotron/issue/227 14:26:26 thanks 14:26:40 what do we want to do about the wiki pages? fp.o/wiki ? 14:26:58 #info now that we don't have phab running unittests on our code, we need to find a new way to have that check run 14:26:59 throw them away? 14:27:12 jskladan: unit test are working with "py.test" command 14:27:40 tflink: the only question I have is regarding this: https://phab.qa.fedoraproject.org/w/blockerbugs/building-for-infra/ 14:27:50 all of the other pages are outdated anyway, I think 14:28:07 unless we want to save them for any archival purposes 14:28:16 kparal: linter is working with "flake8" command 14:28:20 I don't feel much need 14:28:28 that particular page looks like it should move to the fp.o wiki 14:28:48 #action tflink to migrate blockerbugs "building for infra" page from phab wiki to fp.o wiki 14:28:56 tflink: or blockerbugs git. do we have some pages with similar SOPs? 14:29:08 hrm, that's a good point 14:29:11 #undo 14:29:11 Removing item from minutes: ACTION by tflink at 14:28:48 : tflink to migrate blockerbugs "building for infra" page from phab wiki to fp.o wiki 14:29:37 jskladan: the test suite is run always as a whole. but for linters you only want to see your changes. running "flake8 ." is not helpful (try it) 14:30:19 it'd probably be better to put in a README or in the docs that technically already exist for blockerbugs 14:30:26 no idea how badly out-of-date they are, though 14:30:27 kparal: well, then our code should be pep8 valid to start with, no? :) (not that I don't get what you try to say, but still) 14:30:56 jskladan: no it's not, because that would need somebody to make it pep8 valid first 14:31:03 unless we start explicitly excluding the violations that don't matter to us 14:31:07 jskladan: you're welcome to do that, though 14:31:19 tflink: we already exclude quite a lot of violations 14:31:24 kparal: ok, will be done tomorrow 14:31:27 I mean line-by-line 14:31:44 jskladan: also include flake8 output then 14:31:54 kparal: ? 14:31:58 and I don't think there's autoflake8 :) 14:32:21 either fixing the existing violations or excluding each occurrence sounds like a way forward 14:32:36 * tflink is a little concerned about how much time that could take 14:32:48 but I haven't tried to lint all of our codebases for a while 14:33:47 I think we're misunderstanding each other. there's no point in trying to fix existing linter warnings. a lot of effort for little gain. the reasonable way forward is to enforce valid linting on new patches, as we've done for the past year or two 14:34:01 but for that, we need a tool. phab used to do that for us 14:34:09 I don't think that we're misunderstanding eachother 14:34:22 I'm not sure that the tool you talk about is that much less work than just fixing the errors 14:35:04 are you going to fix even all files in the test suite? 14:35:36 and are so many lines changed in the git history worth it? 14:35:37 kparal: testsuite can IMO easily be excluded from lint check 14:35:52 kparal: we had huge diffs before.. 14:36:18 it can be excluded, but then you're back at something running the check, like "make lint" 14:36:52 how is that different from running 'flake8'? 14:37:02 kparal: I don't really see the problem, honestly 14:37:03 which can be 'flake8 .' instead of some way of figuring out the diff and running the linter against that diff 14:37:24 without phab, I can't think of a good way of reliably determining what's changed 14:37:44 make lint develop, diff against develop 14:37:55 or make lint staged, run against git diff --staged 14:38:03 I've seen some oneliners to do that 14:38:15 sounds like we have a volunteer to figure out the tooling there 14:38:20 :) 14:38:23 I already assigned the ticket to myself 14:38:26 ok 14:38:34 if you can find a decent way to do it, I'm not against the idea 14:38:36 and I'm trying to tell you that we've spent too much time on this already 14:38:42 fair enough 14:39:05 any other thoughts/comments/concerns about the migration? 14:39:29 I've tried to replace all the links and notes about phab 14:39:35 if I've missed something, please fix 14:39:41 kparal: the amount of slack in your vigorous rigor, sometimes surprises me :) 14:39:50 I don't know about anything else that's missing from the migration 14:39:57 neither do I 14:40:06 we have not moved any of the files/attachments 14:40:17 but I could not find a way to easily find those in phab 14:40:19 are they needed? 14:40:28 IIRC, they're stored in the FS 14:40:40 I don't think so, just that we discussed it 14:40:56 and the "philes" (or whatever they call it) thing is full of nonsense 14:41:42 yeah, I'm not seeing a quick way to get them from the fs 14:41:49 do we need them? 14:43:26 nope 14:43:33 * tflink takes silence and "nope" as nope 14:43:36 :) 14:43:49 btw: `git diff HEAD^ | flake8 -diff` (or `git diff HEAD | flake8 -diff` for unstaged changes) 14:44:06 jskladan: yes, but you need to exclude non-python files 14:44:11 * tflink wants to go through the wiki to make sure that everything useful has been moved 14:44:25 also, how do you do stuff that's already been committed? 14:44:40 tflink: ? 14:45:07 if I have a feature branch that has multiple commits - I don't think that command would work 14:45:22 unless I'm forgetting how HEAD^ works 14:45:46 yes, but you can replace it with develop 14:46:02 you could do develop or HEAD~10 14:46:27 which is more appropriate, develop or origin/develop? 14:46:38 that depends on what you want :) 14:46:42 nvm, I'm sending this conversation into a rabbit hole 14:46:49 it is 14:46:57 kparal: also, maybe you should try it first, since your computer really usually works differently than min, but the command really only checks python files 14:47:01 anything else on this? 14:47:02 so.. 14:47:03 whatever 14:47:17 jskladan: it seems mine does :) 14:47:38 tflink: can't think of anything else 14:48:04 ok, moving on 14:48:07 #topic Tasking 14:48:15 what are folks planning to work on this week? 14:48:42 tflink: argue with kparal about pep8, it seems :D 14:48:49 other than that, my platter is empty 14:48:51 * tflink is planning to help with getting stg running again and the ansiblize branch of libtaskotron 14:49:23 has anyone looked at https://github.com/fedora-infra/bodhi/pull/1694 yet? 14:49:27 just wondering 14:49:30 oh, I forgotabout upstreamfirst 14:49:33 sigh 14:49:49 I was planning to look at it 14:49:57 but migration took priority 14:50:44 * tflink has not looked at it 14:50:48 me neither 14:51:05 so I'm planning to look at this one, at 'no more alpha' proposal from adam, and help to figure out what's wrong with taskotron-stg if needed 14:51:08 upstreamfirst needs to be upgraded to newest pagure and the status app that roshi hasn't been deployed yet 14:51:21 also I guess I'll need to package the ansiblize version of libtaskotron? 14:51:26 trigger is fubared, AFAIK 14:51:31 on stg 14:51:38 it's spewing lots of TBs to journal 14:52:11 tflink: what's the difference between https://upstreamfirst.fedorainfracloud.org/ and http://pkgs.fedoraproject.org/ with tests/ subdirectory? 14:52:52 kparal: upstreamfirst is a staging area, isn't meant to be long term 14:53:00 tflink: that really is weird... so it sounds like reinstalling the triger/fedmsg-hub is the next step? 14:53:12 from the TBs, that owuld make sense 14:54:05 tflink: also, I learned why nfs works on dev 14:54:19 martin simply turned selinux off, turned the service on, and reenabled selinux 14:54:21 oh? 14:54:25 it will break after reboot 14:54:25 ha 14:54:27 problem solved :) 14:54:52 * tflink thought martin knew better than to just do stuff like that :( 14:55:01 it might be a good idea to have a file with workarounds to current problems :) 14:55:04 sounds like we have work to do on dev/stg, then 14:55:18 at least that's what lbrabec told me, I wasn't speaking to martin directly 14:55:40 so to rephrase my plans for the week: taskotron-stg, upstreamfirst (pagure, uf-monitor), then libtaskotron's ansiblize branch 14:56:03 losing folks makes such a positive impact on velocity, doesn't it? 14:56:29 nobody is slowing us down! 14:56:36 that's what you meant, right? 14:56:44 I suppose that's one way to look at it 14:57:02 anyhow, I'm just whining at this point 14:57:03 I was also quite surprised, that doing manual overrides, instead of putting it to ansible, was supposedly "the way" 14:57:07 but who am I to argue 14:57:09 it's not 14:57:33 the only time that's OK is if prod is broken and we need to get it working while a better fix is found 14:57:34 good to know, then 14:58:05 or if we're waiting on a fix to make it into the repos 14:59:14 anything else? 14:59:23 * tflink is surprised that this took the whole hour 14:59:36 a few general questions regarding ansiblize, perhaps 14:59:54 kparal: good for a meeting or ML, IRC later? 15:00:06 either way 15:00:21 let's close this and continue on fedora-qa 15:00:23 IRC later, then. 15:00:28 sounds good to me 15:00:32 #topic Open Floor 15:00:37 nothing here 15:00:39 Any other topics that you all want to bring up? 15:00:46 for the three of us, anyways :-/ 15:01:28 * tflink lights the fuse 15:01:39 thanks for coming, everyone 15:01:43 * tflink will send out minutes shortly 15:01:45 #endmeeting