15:00:38 <tflink> #startmeeting fedora-qadevel
15:00:38 <zodbot> Meeting started Mon Feb 23 15:00:38 2015 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:38 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:43 <tflink> #meetingname fedora-qadevel
15:00:43 <zodbot> The meeting name has been set to 'fedora-qadevel'
15:00:52 <tflink> #topic init
15:01:03 <tflink> #chair kparal, mkrizek
15:01:03 <zodbot> Current chairs: kparal mkrizek tflink
15:01:08 * kparal is here
15:01:33 <tflink> #info for folks reading this later - the lack of an announce was a mistake - this wasn't intended to be an impromptu meeting
15:02:02 * jskladan is here
15:02:06 * mkrizek is here
15:02:12 <jskladan> got distracted by Alembic :)
15:02:20 <tflink> cool, I think we have everyone who I expect to show up given the lack of notice
15:02:37 <tflink> #topic purpose
15:02:59 <tflink> before we get started, figure that I should mention the slightly different purpose for this meeting that we're going to try
15:03:18 <tflink> #info we're going to start doing qadevel meetings weekly, right before the qa meetings
15:03:51 <tflink> #info the idea is to have quick meetings to discuss status, plans and if anyone is hitting issues. if the meetings start getting consistently long, we'll move back to fortnightly
15:04:41 * danofsatx is eavesdropping
15:04:49 <tflink> that being said, I'll send out an email to qadevel@ about this later today
15:05:00 <tflink> on to ...
15:05:06 <tflink> #topic status
15:06:01 <tflink> just looking for a quick note on status and if you are hitting any issues that other folks could help resolve (but probably leave details for outside the meeting)
15:06:11 <tflink> jskladan: could you start with execdb?
15:07:14 <jskladan> #info Initial 'use ExecDB in taskotron' goal is done, and the whole stack is now running at  http://taskotron-demo.cloud.fedoraproject.org/
15:07:38 <tflink> #chair jskladan
15:07:38 <zodbot> Current chairs: jskladan kparal mkrizek tflink
15:08:09 <jskladan> today I have pushed some stuff to phab for review, and the last blocking diff (resultsdb) is at the moment blocked by me trying to make use of Ansible
15:08:33 <jskladan> I suppose that the ResultsDB diff will be up for reivew tomorrow
15:08:40 <tflink> cool, looking forward to seeing that run for a while. hopefully we can get it on dev before too long
15:09:21 <jskladan> #info Initial 'use ExecDB in taskotron' goal is done, and the whole stack is now running at  http://taskotron-demo.cloud.fedoraproject.org/
15:09:48 <jskladan> #info most of the bits are up for review in Phab, the rest will land there tomorrow
15:10:03 <jskladan> questions?
15:10:10 <tflink> jskladan: which one of us will be updating the taskotron-demo machine?
15:10:37 <jskladan> updating with the current code, or the underlying os?
15:10:44 <tflink> the underlying os
15:11:11 <jskladan> I can take care of it, if it is not more complicated than a regular yum-update
15:11:38 <tflink> as long as none of the deps break something, it shouldn't be any more complicated than yum updates and reboots for new kernels
15:11:50 <Corey84> .fas corey84
15:11:51 <zodbot> Corey84: corey84 'Corey84' <sheldon.corey@gmail.com>
15:12:02 <tflink> we just have a less than spotless record on updating cloud VMs :-/
15:12:26 <jskladan> tflink: OK, I'll add the `yum update` on that machine it to my weekly to-do list
15:12:35 <tflink> cool, thanks
15:12:44 <tflink> anything else on resultsdb?
15:12:48 <jskladan> #info jskladan will take care of regularly running `yum update` on taskotron-demo.cloud machine
15:12:54 <tflink> er, resultsdb/execdb
15:12:54 <jskladan> not at the moment
15:12:58 <jskladan> ^^
15:13:21 <tflink> mkrizek: can you give a quick status on task artifacts?
15:13:25 <mkrizek> sure
15:13:36 <mkrizek> libtaskotron patches are in develop
15:14:06 <mkrizek> ansible pieces are up for review, once accepted, I'll test it on dev
15:14:10 <tflink> #info libtaskotron changes to support task artifacts are in develop, not released yet
15:14:45 <tflink> #info system support changes for public artifacts are still pending review of ansible playbook bits, will deploy to dev once that's done
15:15:00 <mkrizek> other that that, trigger needs to be patched, which is part of execdb work, until it is ready for prod, we can generate "dummy" uuid's in trigger
15:15:29 <mkrizek> that's all I guess
15:15:47 <tflink> we might want to think about a migration process, too - make sure that we won't have conflicts once we start using UUIDs from execdb
15:16:11 <kparal> nuke the db? ;-)
15:16:12 <jskladan> uuid1 scheme should IMHO guarantee it
15:16:31 <jskladan> as long as we don't create more than 100k (IIRC) uuids per second
15:16:39 <tflink> kparal: sure, who needs results :) we can task you with rebuilding history by hand
15:16:48 <kparal> who needs history...
15:17:08 <tflink> jskladan: I assume that it's trivial to generate uuid1 uuids?
15:17:17 * tflink still hasn't looked into the details of that scheme
15:17:49 <tflink> #info still need to patch trigger to generate pseudo UUIDs until execdb is in place
15:18:04 <jskladan> yup:
15:18:04 <jskladan> import uuid
15:18:04 <jskladan> uuid.uuid1()
15:18:45 <tflink> easy is good :)
15:19:35 <tflink> mkrizek: anything else on artifacts? it sounds like you'll be able to get it working in dev in the next couple of days - am I misunderstanding something?
15:20:13 <jskladan> ad collisions - as far as one can trust stack-overflow: http://stackoverflow.com/a/1785592 http://stackoverflow.com/a/786541
15:20:15 <mkrizek> nope, *should* be on dev real time soon
15:20:26 <tflink> sounds good
15:20:50 <tflink> #info if everything goes according to plan, should have public artifacts working on taskotron-dev later this week
15:21:13 <tflink> kparal: can you give an update on the changes you've been working on for upgradepath?
15:21:19 <kparal> sure
15:21:34 <kparal> so I tried to implement two things at once, because they are closely related
15:21:49 <tflink> jskladan: if we create that many uuids at once, I think we'll have other problems :)
15:21:52 <kparal> first, generate some artifacts from upgradepath, so that we have something to test our new code with
15:22:10 <kparal> currently I generate per-build and per-update log files
15:22:40 <tflink> #info in the process of enhancing upgradepath to generate artifacts so we have something to test the new artifacts-storing code with
15:22:52 <kparal> and the second thing was to modify the code to actually be able to per-build results, and expose it in TAP, which was a bit of pre-requisite for this
15:23:04 <kparal> the patch is now waiting for review in Phab
15:23:28 <tflink> #info the new code is generating per-build and per-update artifacts to be more easily compatible with fedmsg emission
15:23:40 <tflink> it's on my todo list for today
15:23:45 <kparal> I don't really need you to verify the functionality, I know no one but me is really familiar with the code (and it's quite ugly code, due to a lot of autoqa->taskotron transformations and stuff)
15:23:59 <kparal> just look at it if you see something really weird or invalid, thanks
15:24:06 <kparal> works on my machine, if that helps :)
15:24:20 <tflink> and I suspect that it's going to remain somewhat ugly until we make the time for you to clean it up :-/
15:24:35 <kparal> and write some unit tests, yeah
15:24:48 <kparal> but I tested it manually quite extensively
15:24:51 <mkrizek> and lower bus factor ideally as well
15:24:54 * tflink will try it locally, not sure how we're going to get the new code just working on dev but that's more of a sysadmin thing, I think
15:25:34 <kparal> that's all from me
15:25:38 <tflink> thanks
15:26:23 <tflink> I've been working to get more tickets for no-cloud disposable clients done but I'm coming to the conclusion that more docs are needed before I get much farther
15:26:39 * tflink sees some quality time with rst and inkscape in his immediate future
15:26:43 <kparal> what docs in particular?
15:26:53 <kparal> oh, design documents?
15:26:58 <tflink> describing how the disposable clients will work
15:27:04 <tflink> the stuff that we talked about last week, mostly
15:27:09 <kparal> I see
15:27:31 <tflink> still haven't gotten the design stuff documented and it's hard to write decent tickets when there's nothing to support the tasks contained :)
15:28:01 <tflink> I've got a couple of tickets written up, but more will be coming
15:28:28 <tflink> #action tflink to finish writing up design documents based on conversations in brno last week
15:28:58 <kparal> just create some basic sketch-ups and we can participate trying to filling in the blanks
15:29:12 <tflink> will do - any objections to using the phab wiki?
15:29:25 <kparal> none here
15:29:42 <mkrizek> nope
15:29:47 <kparal> I wonder if I can subscribe to its changes globally
15:29:52 <kparal> and not per-document
15:30:00 <tflink> one would think so
15:30:04 <kparal> per-project would be nice
15:30:07 <jskladan> yup, would be great
15:30:09 <kparal> I'll try and have a look
15:30:28 <tflink> which reminds me that I never deployed the new phab version to production
15:30:46 <tflink> there have been a bunch of wiki permission changes recently, not sure which version has them
15:31:54 <tflink> I think that's about it on disposable clients
15:32:19 <tflink> #info more disposable client related tasks will be created in phabricator as design documents are finished
15:32:33 <tflink> depcheck hasn't really changed state in the last couple weeks
15:33:08 <tflink> #info depcheck is having problems way too often in production, planning to spend a couple of hours on it once the next failure shows up
15:33:37 <tflink> #info still waiting to see another bad failure in production, nothing in the last week.
15:34:00 <tflink> it occurs to me that topics for each of these would have made the minutes easier to read. oh well
15:34:36 <tflink> #info need to update devel@ with our plans for depcheck (mostly leave it in current state for now, look at it more once we have more progress on disposable clients)
15:35:26 <tflink> I think that's it with depcheck - I'm keeping an eye out for failures with a script that displays failures over the last XX hours
15:35:37 <tflink> any status that I'm forgetting?
15:35:39 * tflink thinks not
15:36:18 <tflink> #topic public deployment state
15:36:35 <tflink> libtaskotron-0.3.11 has been in dev for almost a week now
15:36:58 <tflink> IIRC, no new failure modes have been introduced, would like to move it to stg today or tomorrow - production shortly thereafter
15:37:42 * tflink wants to get the beaker snapshot importing task running soon
15:38:03 <tflink> any objections or new failures that I'm not aware of with the new version?
15:38:34 <jskladan> nope
15:38:47 * mkrizek didn't notice anything
15:38:51 <tflink> k, moving on
15:38:59 <tflink> #topic tasks for this week
15:39:16 <tflink> this isn't going to work incredibly well due to the lack of tasks for disposable clients
15:39:26 <kparal> should we leave that outside of the meeting, with just those who have already finished all their tasks, in order to keep the meeting time short?
15:39:44 * tflink thinks that folks mostly have enough to keep busy for the next couple days
15:39:46 <kparal> or did all of us finish their tasks?
15:40:05 <tflink> works for me, not like there's much to discuss in detail today, anyways :)
15:40:15 * mkrizek still has tasks to do
15:40:22 <tflink> this is already taking longer than I was hoping
15:40:29 <kparal> ok
15:40:45 <tflink> which moves us on to
15:40:49 <tflink> #topic open floor
15:41:12 * tflink would also like to try something that he does with in-person meetings
15:42:00 <kparal> what exactly?
15:42:04 <tflink> could folks give a quick rating on how useful this was? from 1-5 with 5 being "this is the best use of my time that I could imagine" and 1 is "I'm writing a bot to take my place if this ever happens again because staring at my toes would be a better use of time"
15:42:55 <kparal> personally I very much like seeing a quick status weekly chat with everyone involved
15:43:14 <kparal> planning and similar stuff is probably much more time consuming, so I would do it outside of the meeting
15:43:27 <tflink> suggestions on how to make things faster/better would also be appreciated
15:43:43 <jskladan> I'd say 3.5 - I'd try to make just status updates at the beginning
15:43:47 <jskladan> and we can then discuss later
15:44:03 <tflink> kparal: I think there's value in talking about who's working on what at a higher level in the group - maybe not every meeting, though?
15:44:03 <kparal> yeah, prepare some notes to copy&paste. I'll try to have it next time as well
15:44:05 <jskladan> but I know that it sounds a bit utopic
15:44:46 <kparal> tflink: yes, we should do that from time to time, but we probably don't need to do that regularly
15:44:49 <mkrizek> can we do one week just status reports and do other things like planning etc. bi-weekly?
15:45:12 <jskladan> would make sense to me
15:45:18 <tflink> yeah, we can try doing that
15:45:30 <tflink> start next week?
15:46:04 <kparal> let's try
15:46:21 <tflink> sounds good to me
15:46:28 <mkrizek> cool
15:46:38 <tflink> anything else to discuss?
15:46:44 * tflink will close out the meeting otherwise
15:46:52 <jskladan> expanding on the "text prepaired for copy-paste" do you guys think it would be worth creating a document in advance?
15:47:11 <mkrizek> like public document?
15:47:12 <kparal> jskladan: you mean something publicly available?
15:47:28 <kparal> we already have weekly status reports, so it should be at least partially included in there
15:47:46 <jskladan> I meant having some etherpad document with the topics and infos
15:47:49 <jskladan> pre-meeting
15:47:54 <tflink> yeah, but those aren't public and only apply to fedora-qe folks
15:48:15 <tflink> by those, I mean the status reports that kparal was talking about
15:48:22 <kparal> I assume people will be creating notes just an hour or two before the meeting. you can't create it two days in advance, if you want to describe a week-worth of work :)
15:48:48 <tflink> I can create a wiki page for next week if we want to try that
15:48:49 <mkrizek> or 5 minutes before rather :)
15:48:53 <jskladan> nope, but if we have a set of topics
15:48:56 <tflink> otherwise, maybe creating a template would work better
15:49:14 <jskladan> you could add the notes in advance
15:49:14 <tflink> ie "here's a suggested format to use for status"
15:49:57 <jskladan> I'm not pressing the issue, just seemed like a way to spare some of my "slow typist" time during the meeting
15:50:26 <kparal> I'm not sure if I see big advantage of having it inside my gedit vs in an etherpad, but I don't object either way
15:50:49 <tflink> let's try for the "template" and "tflink not forgetting to announce the meeting" for next week
15:51:07 <tflink> if that doesn't help, we can try for the public documents
15:51:15 <mkrizek> works for me
15:51:45 <jskladan> tflink: if we at least have the topics summed-up in the template, I think it should be enough for now
15:52:35 <kparal> so you mean a meeting agenda
15:53:14 <tflink> #action tflink to send out description of "new" meeting style, including suggestions for template to use for status updates
15:53:21 <jskladan> what I mean is meeting agenda created in advance with all the #info clauses per affected party
15:54:02 <kparal> I'm beginning to understand the idea
15:54:16 <tflink> I'm fine with trying either method
15:54:40 <tflink> but I suspect that folks will be writing up their #info right before the meeting :)
15:55:32 * tflink would prefer to try the simpler, lighter process method first, though
15:55:39 <kparal> +1
15:55:43 <jskladan> ^
15:55:49 <mkrizek> +1
15:55:56 <tflink> if that doesn't work, we can try for the pre-filled agenda
15:56:26 <tflink> to be clear - I'm proposing that we try having folks write up their own #infos before the meeting and just paste them into IRC
15:56:43 <tflink> hopefully that will speed things up quite a bit
15:56:53 <tflink> sound good?
15:56:54 <kparal> ack
15:56:57 <mkrizek> ack
15:57:10 <jskladan> ack
15:57:19 <tflink> sorry for this taking so long - I suspect that it may take some tweaking to get faster
15:57:28 * tflink was really hoping not to use up the entire hour :-/
15:57:38 <kparal> we still have 3 minutes left ;)
15:57:43 <jskladan> :D
15:57:51 <jskladan> and we started late...
15:57:54 <kparal> quick, end the meeting!
15:58:08 * tflink will send out minutes shortly
15:58:09 <kparal> oh no, just 2 minutes now...
15:58:14 <tflink> #endmeeting