16:00:22 #startmeeting fedoraqa-devel 16:00:22 Meeting started Mon May 19 16:00:22 2014 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:22 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:28 #meetingname fedoraqa-devel 16:00:28 The meeting name has been set to 'fedoraqa-devel' 16:00:33 #topic Roll Call 16:00:45 Who all's here for the QA devel meeting? 16:00:53 o/ 16:01:00 hello 16:01:25 mkrizek said that he'd probably be 10 minutes late or so 16:01:41 * handsome_pirate waves 16:01:53 jskladan didn't say anything but he hasn't been responding to IRC, so I suspect that he won't be attending 16:01:55 Actually, I'll be right back, have to run down stairs 16:01:57 hey 16:03:39 * tflink waits another couple minutes for folks to show up 16:04:06 * roshi pictures handsome_pirate chasing stairs down and tackling them 16:04:25 #chair roshi kparal 16:04:25 Current chairs: kparal roshi tflink 16:05:13 * satellit listening in 16:05:23 #info proposed agenda: https://lists.fedoraproject.org/pipermail/qa-devel/2014-May/000901.html 16:05:26 * mkrizek joins 16:06:02 mkrizek: welcome! we're just about to get started 16:06:15 there are plenty of things to go over, so let's get started 16:06:22 #topic Taskotron 0.1 Retrospective 16:07:06 we released taskotron 0.1 on Friday but the original plan had been to be done with all of phase 1 by march 1 16:07:36 I think that there was some overly-optimistic planning, but I'm interested to see what other folks thought about how things have been going so far 16:07:46 what went well? 16:08:12 I like the fact that we now have processes for code review and our test coverage is much better than it used to be 16:08:26 agreed 16:08:30 I think phabricator proved itself to be a great tool for what we're doing 16:08:31 IMHO, taskotron's code base is much better than autoqa 16:08:41 we have tests 16:08:41 I think there were a lot of new things we needed to learn, like working with pytest properly, so that made the whole effort longer. but I'm quite satisfied we did that 16:08:53 and our tooling is way better than before 16:09:10 yeah, I didn't anticipate the learning curve for code reviews and unit tests when I wrote up the original plan :) 16:10:10 #info generally agreed that while our process changes were more expensive than anticipated, they have been worth the effort so far 16:10:34 are there things that didn't work well or could have been improved? 16:10:44 could have been, should be 16:11:18 * danofsatx-work is late 16:11:21 * tflink is of the opinion that lack of overlap in working hours was an issue - is working to fix that on his end 16:11:59 perhaps a clearer roadmap for what kinds of things connect and where they connect would have been helpful for people looking in 16:12:00 in the beginning we spent a lot of time discussing things into large detail before committing the change. now we have more iterative process, which I think works better 16:12:00 how much of a problem was lack of direction or unclear goals? 16:12:38 there were too much of discussions in the code reviews about things that were not directly related to the code under the review rather than future goals 16:12:48 * roshi felt he had clear direction for his tasks at least 16:13:03 kparal is faster :/ 16:13:27 I think that generally smaller code reviews have also helped there 16:13:38 as for general goals, we might need a better specification of what is important and what is less important. but it's quite hard to evaluate these things 16:14:23 that was kinda what I was hinting at kparal 16:14:32 roshi: yeah, I want to have better external communication going forward. it should get easier as we have more concrete things to talk about 16:14:33 * handsome_pirate returns 16:14:39 for sure 16:15:19 it's one of those things I think where people see "Taskotron" and think a single thing, when really it's a framework and a bunch of moving pieces that don't seem connected at first 16:15:23 kparal: I tried to mark the possible tasks for 0.2 with importance (from my POV anyways), do you think that'll help? 16:15:23 at this stage anyway 16:16:22 * tflink is planning to start some blog posts, talking about the different components and how they all fit together 16:16:31 tflink: yeah, I think we need documents like that one. maybe also some notes about higher level direction - e.g. which checks are top priority, whether the framework is more important than other pieces, etc 16:17:49 are we ready at this point for people to write arbitrary tasks? 16:18:11 kparal: as in docs to facilitate planning or more general documentation on direction? 16:18:13 of course I don't want to have a large bureaucracy dictating what gets done and when. but just some hints of what we want to achieve first, and second, ... 16:18:21 roshi: no, not even close 16:18:48 task contribution is possible but we haven't started to address the disposable client issue, which is required for arbitrary tasks 16:18:56 I didn't think so - but that's a point we want to advertise when we get there 16:19:31 kparal: yeah, I think it'll be a process of figuring out how much documentation/process is just enough without going overboard 16:20:02 one question I get from people is when will taskotron be able to run _their_ check. at the moment, I'm not even sure whether we have the slightest idea :) 16:20:18 depends on the check 16:20:43 at the moment, the only group that has somewhat concrete plans for taskotron is the cloud WG 16:21:03 but I suspect that we're about to be inundated with "when will X be ready" questions and requests 16:21:13 for sure 16:21:36 I'll be working with cloud to get their checks written once we're to that point 16:21:36 at some point, we'll have to start figuring out which bits to work on first, but that's a bit out of scope for today 16:22:00 ok 16:22:15 to be clear: just because semi-arbitrary tasks aren't ready doesn't mean that we can't add external tasks 16:22:33 it just means that folks would need to work with us a bit more directly 16:22:41 the current priority is still replacing AutoQA 16:23:22 to make sure that we're all on the same page, takeaways from 0.1 are: 16:23:51 1) more details/information on direction of taskotron and priority of different tasks would be useful 16:24:16 2) better communication on status for external groups is needed 16:24:48 did I miss anything? 16:24:53 not that I see 16:25:17 ok, moving on 16:25:25 #topic Release Schedule 16:25:38 one of the things I want to try is a time-based release schedule 16:25:54 starting with releasing every 2 weeks instead of "when X is done" 16:25:57 so, sprints? 16:26:04 pretty much, yeah 16:26:26 how onto the agile bandwagon did you have in mind? 16:26:39 depends on which agile you're thinking of 16:26:45 touche :p 16:27:01 the Right Way Agile, of course 16:27:13 roshi: I don't think that such a singular thing exists 16:27:19 I think two weeks is a good starting place 16:27:22 for now, this would mean: 16:27:32 I don't think it exists - but people claim to have It all the time :) 16:27:46 1) bi-weekly IRC meetings (schedule TBD) to discuss the previous iteration and plan the next one 16:28:16 2) smaller tickets - if it can't realistically fit into a 2 week iteration, it needs to be broken up into subtasks 16:28:44 any thoughts or objections about my proposal? 16:28:50 so often do we update staging and how often production with 2-week release cycle? 16:29:14 right now, it's an arbitrary delay 16:29:39 is 2 week IRC meeting offset with release schedule? 16:29:44 or same day? 16:29:56 once we get proper dev, stg and prod environments I'd like to do something like: 16:30:05 dev: updated with CI on change to develop 16:30:18 stg: updated during release 16:30:40 prod: updated after X time to ensure stability (X would be up for debat) 16:30:59 there's some extra effort connected with each release (packaging, writing release notes, announcements, update servers, etc). can 2 weeks be too short to justify this effort, or is it OK? 16:31:09 danofsatx-work: depends on when we can get folks in a meeting, ideally the first day of an iteration 16:31:33 kparal: for the moment, there is a lot of overhead here - it took me hours to do all the release tasks last week 16:31:53 that's why I ask 16:31:55 but I'd like to get that all automated in CI, so the eventual overhead wouldn't be so bad 16:31:59 all/most 16:32:24 for now, I'm of the opinion that the manual overhead is worth getting into a rhythm 16:32:33 alright 16:32:45 but that does remind me that we need to start keeping release notes 16:33:04 which should be updated with features as they're done 16:33:23 I'd start with a git log link :) 16:33:48 as long as we keep reasonable commit descriptions 16:33:49 that would work for now, we seem to be pretty close to 1:1 devel-commit:feature 16:34:29 is anyone interested in looking for an existing git-log:rst tool? 16:34:35 interested in, willing to 16:35:11 otherwise I can do it 16:35:42 #action tflink to look into tools for generating release notes based on git log 16:35:50 can't we just link to it? 16:35:58 #undo 16:35:58 Removing item from minutes: ACTION by tflink at 16:35:42 : tflink to look into tools for generating release notes based on git log 16:36:13 #action tflink to look into tools for generating release notes based on git log or just linking to log if too troublesome 16:36:30 kparal: I'd prefer having the rst generated in the docs, but I'm not sure it's worth the effort at this time 16:36:49 I can look at that tflink you got enough 16:36:56 #undo 16:36:56 Removing item from minutes: ACTION by tflink at 16:36:13 : tflink to look into tools for generating release notes based on git log or just linking to log if too troublesome 16:37:03 * roshi was getting coffee 16:37:06 #action roshi to look into tools for generating release notes based on git log or just linking to log if too troublesome 16:37:22 roshi: just don't spend too much time on it, a couple hours at most 16:37:24 :) 16:37:31 sgtm 16:37:37 any other thoughts on this? 16:38:10 proposed #agreed start doing an agile-ish iterative release process, initially set to 2 week iterations 16:38:16 ack/nak/patch? 16:38:19 ack 16:38:21 ack 16:38:23 ack 16:38:25 #agreed start doing an agile-ish iterative release process, initially set to 2 week iterations 16:38:32 cool, moving on to 0.2 planning 16:38:39 #topic Taskotron 0.2 Planning 16:38:50 #link https://phab.qadevel.cloud.fedoraproject.org/w/taskotron-0.2/ 16:38:58 hrm, I forgot to file a 0.2 tracking ticket 16:39:14 that's a list (login required, sorry) 16:39:25 of tasks that I think could be appropriate for 0.2 16:39:44 I'm not 100% on who's participating at what level, but my initial thoughts on task assignments are: 16:40:15 mkrizek: would you take 171 and 173? assuming that you haven't gotten very far with 169? 16:40:31 * mkrizek looks 16:40:32 T143 sounds like my task 16:40:45 kparal: would you be willing to take 169 and 143? 16:41:02 sure 16:41:06 tflink: I am ok with that 16:41:19 I'll have to find out what the hell is that jinja 16:41:25 jskladan said that he wanted to start helping with depcheck, so I was thinking 166 but he's not here right now 16:41:34 * tflink will sync up with him tomorrow, hopefully 16:41:45 sign him up for it! ;) 16:42:22 that leaves 2 tasks with a priority of 1 16:42:36 T172 and T44 16:42:49 does 171 mean that triggers will be configurable by administrator, or that checks themselves will be able to choose whether to respond to that event or not? 16:43:08 kparal: configurable in the trigger was what I had in mind 16:43:16 so, outside of the task 16:43:18 ok. start small 16:43:43 yeah, controlling schedule in the task is an interesting thought but that's a rather large task :) 16:44:16 I suspect that T172 will fall to me since I've yet to get anyone else involved in our infra 16:44:28 will/could 16:44:49 roshi: do you think you understand how bodhi reporting works well enough to do the non-deployment parts of T172? 16:44:52 upgradepath still has no unit tests. what priority is that? 16:45:04 tflink: is deploying fake_fedorainfra similar to deploying blockerbugs? 16:45:13 tflink: Right quick, what is 166? 16:45:20 handsome_pirate: yumrepoinfo task 16:45:25 s/task/directive 16:45:29 honestly, couldn't tell you - but due to proximity I think you could get me spun up pretty quick 16:45:31 mkrizek: yeah, it should be 16:45:53 tflink: can help with that if needed then 16:46:00 I suspect that fake_fedorainfra is going to require some tweaks 16:46:01 tflink: Ah, the bit I'm waiting on :) 16:46:43 in my experience, one of the biggest problems with changing to an agile-ish project planning scheme is estimation 16:47:12 estimation is hard and I'm expecting that it'll take us a few iterations to start getting close to accurate 16:47:30 for sure 16:47:34 mkrizek: do you think you'd have the time for that in 2 weeks on top of the otehr 2 tasks? 16:48:26 my suggestion for learning how to make estimates is to start with how long you think it'll take. then double or triple that and use that as your working estimate 16:48:33 tflink: I'd rather say "no" since I haven't studied the 2 tasks in much detail 16:48:36 tflink: we could get together and whieboard it out then if I have any other questions I can ping mkrizek 16:48:47 s/whieboard/whiteboard 16:49:08 roshi: fake_fedorainfra is a pretty simple app overall, I don't think you'll have much trouble with it 16:49:22 our bodhi reporting strategy and verifying that everything works is a bit more complicated 16:49:22 I just haven't seen/looked at it :) 16:50:02 does everyone think that they'll be able to do the tasks mentioned in time for a release next friday? 16:50:13 ie, merged into develop by next wed or thur? 16:50:59 that depends how controversial my patches will turn out to be :) 16:51:07 fair enough :) 16:51:32 did I miss anyone for task assignment? 16:51:40 other than pschindl 16:52:21 and the fedora-qe interns - will sync up with them/kparal about that after the meeting 16:52:24 I'll talk to pschindl this week about possible tasks 16:52:38 the interns have been missing in action for the last month 16:52:40 assuming that he's recovered from his bout with the plague, anyways :) 16:52:43 exam period or something 16:53:07 I'm not sure whether they'll be available this or the following week 16:53:22 at least jsedlak is out till this thursday 16:53:38 so I assume they won't 16:53:42 sounds like we won't count on them for much this iteration 16:54:12 I tried to take a look at 171 since infra was mentioned, but I can't log into phabricator due to lack of a @fedoraproject.org email adx 16:54:22 I haven't filed tickets for this yet, but I'm planning to work on infra planning and buildbot hacking 16:54:29 danofsatx-work: do you have a FAS account? 16:54:36 yes 16:54:51 it didn't take that one though - I tried with it first 16:55:06 danofsatx-work: @fedoraproject.org didn't work? 16:56:00 it took that one. 16:56:02 I'm planning to have a detailed conversation with nirik and smooge at the bodhi2/taskotron FAD next month and there are still a lot of unanswered questions on what our infra needs to look like 16:56:20 now, off to figure out how to set up @fp.o email.... 16:56:36 are folks ok with me glossing over the details on that task since we're almost at an hour? 16:56:48 danofsatx-work: it should redirect to the email you have set in FAS 16:57:00 there are still a couple of topics I wanted to touch on 16:57:05 really? cool....I'll wait 16:57:40 tflink: sure, go on 16:57:47 * tflink assumes silence means yes :) 16:58:01 #topic General Questions 16:58:16 some of these are going to end up being future topics, but I wanted to bring them up 16:58:49 I'd like to start requiring a CLA for direct taskotron contributions 16:59:17 is that something we can handle via a FAS group or something else? 16:59:19 nothing too draconian, though. along the lines of "you can relicense my contributions as any of the set of X licenses" 16:59:45 for sane values of X (fsf licenses, apl2 maybe) 16:59:57 that's probably best for qa-devel discussion 17:00:04 roshi: possibly, not sure how exactly it'd be managede 17:00:07 in essence I agree, but some people might have objections 17:00:16 kparal: agreed, just wanted to mention it here first 17:00:21 just a thought - means we don't have to do too much special :) 17:00:22 external contributors mainly, I think 17:00:40 kparal: yeah, but I'd like to cover everyone just to be safe 17:00:52 future-proof our license-ability :) 17:01:17 we will probably need to say something like "this code will always remain copylefted by a FSF approved license". because if we said only "FSF-approved", some people might not like the idea of converting it to BSD for example 17:01:28 of course, unless that's our intention 17:01:33 I believe it isn't 17:01:53 kparal: yeah, language of the CLA is TBD. I'm not thinking BSD/MIT for future releases, though 17:02:06 with our current codebase, we're restricted to gpl-compatible licenses anyways 17:02:23 other items: 17:02:44 there's this website from Canonical that generates these legal descriptions. but I'm not sure whether it fits our intentions 17:02:58 kparal: some of them do, it depends on the exact CLA 17:03:07 some of them are fsf-generated licenses only 17:03:39 a question, though 17:03:41 I'm going to start working on CI for taskotron as I have time. there are some infra changes needed and those tickets have been started 17:04:04 if somebody contributes a patch to GPL2+ project, do we need his consent to relicense to GPL3+? I don't think so 17:04:28 #action tflink to start thread on qa-devel@ about CLA for taskotron and the details of what would be included in said CLA 17:04:53 so I'm not exactly sure whether CLA helps us in some way, other than future-proofing 17:04:55 kparal: it's formalizing that and ensuring that if we ever had to relicense backwards (ie gpl3 -> gpl2) for any reason, we could 17:05:09 tflink: ah, good point 17:05:26 also http://jacobian.org/writing/contributor-license-agreements/ 17:06:18 I'd like to start reviewing core tasks (rpmlint, upgradepath, future depcheck) in phabricator - submitting them to the same scrutiny as the other bits we produce 17:06:31 that makes sense 17:06:34 not all tasks - that'd be crazy. just the ones that we're directly creating and supporting 17:06:54 especially since they'll be the examples people work off of 17:07:20 I think that's it from me - the other things can be sent to the list 17:07:29 #topic Open Floor 17:07:46 so we need to clone the repos in Phab, right? 17:07:51 and create proper projects 17:07:58 Any topics that I missed or that folks want to bring up 17:08:00 kparal: yep 17:08:04 ok 17:08:07 +1 there 17:08:13 #action tflink to add task repos to phab and create projects 17:08:33 Oh, one more thing: I want to update phabricator on qadevel soon 17:08:50 the current version has a public landing page, among other improvements 17:09:00 like allowing more direct FAS auth 17:09:21 the public wiki page support still isn't quite there but there is movement towards that 17:09:41 sounds good 17:10:14 I don't know if it's just me, but if I have a ticket in Phab open, it eats 50% of my CPU. looking forward to a new version 17:10:16 I'll send out an email before updating the production instance but an update to arcanist may be required 17:10:33 * tflink hadn't noticed that issue 17:10:38 (the tab has to be active, background tab doesn't eat anything) 17:11:20 kparal: do you see the same issue in stg? 17:11:28 that's a newer build than production 17:11:55 oh, one more thing for peoples' radar: the hostname for qadevel will be changing in the semi-near future 17:12:08 * kparal needs to check 17:12:26 there will be redirects in place, so links shouldn't break but I'm planning to move off of the current cloud instance so that we can have CI 17:12:54 since we're 15 minutes over already, if there's nothing else ... 17:13:03 nope 17:13:12 * tflink engages the patent-pending qa quantum fuse for [0,5] minutes 17:13:33 thanks for running this 17:13:50 tflink: any plans to revive beaker? 17:13:50 np, thanks for participating, everyone! 17:14:09 or basically it is being tracked in phab ticket? 17:14:13 vrutkovs: nothing specific at the moment - we're stuck on a f20 interaction bug right now 17:14:19 okay 17:14:25 have you seen http://rpm-ostree.cloud.fedoraproject.org/ also? 17:14:37 it was working with a F19 virthost but as soon as I updated to F20 ... boom 17:15:01 vrutkovs: I'm aware of it but haven't looked into it too deeply yet 17:15:02 this might be useful tool to get updated rawhide - also as a viable platform to run desktop tests also 17:16:03 vrutkovs: if I re-imaged the beaker virthost to F19, would you use it? 17:16:28 I don't see having the time to figure out the pxe-bustedness with f20 vms anytime in the next couple of weeks but a reimage is pretty simple 17:16:29 tflink: yes, definitely - for beaker I'd even prefer something even more stable / supportable 17:16:50 k, I'll try to get that done today 17:17:09 #action tflink to reimage beaker virthost as F19 to workaround pxe-bustedness 17:17:15 tflink: cool, thanks 17:17:44 figuring out how to make F20 vms pxe without x is going to be a problem, though 17:17:56 without a graphics adapter, rather 17:18:16 bah, I'm not phrasing that well 17:18:39 figuring out how to make VMs pxe on an F20 virthost without a graphics adapter will be a problem in the future 17:19:28 if there are more questions, discussion - #fedora-qa, qa-devel@ and test@ are the places for that! 17:19:33 * tflink will send out minutes shortly 17:19:38 Thanks for coming, everyone! 17:19:41 #endmeeting