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