16:01:21 <tflink> #startmeeting fedoraqa-devel
16:01:21 <zodbot> Meeting started Thu Jan  9 16:01:21 2014 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:21 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:26 <tflink> #meetingname fedoraqa-devel
16:01:26 <zodbot> The meeting name has been set to 'fedoraqa-devel'
16:01:31 <tflink> #topic Roll Call
16:01:38 * roshi is here
16:01:44 * jskladan is here
16:01:49 <tflink> Who all's ready for some wonderful meeting party time?
16:02:04 * satellit listening
16:02:13 * tflink suspects that this won't quite live up to blocker review meeting level of fun, though
16:03:02 * handsome_pirate waves
16:03:03 * kparal is here
16:03:06 * croberts waves
16:03:06 * nirik is lurking, but busy, ping me if I can help with anything.
16:03:09 * Viking-Ice sharpens his ax
16:03:09 * Viking-Ice code chops *chop* *chop* *chop* *chop*
16:03:19 <Viking-Ice> sharp as an elven arse
16:03:25 <handsome_pirate> lol
16:03:25 * pschindl is here
16:03:36 <tflink> Viking-Ice: don't think I've heard that one before :)
16:04:52 * danofsatx is listening only
16:04:53 <Viking-Ice> tflink, similar quote made in baldurs gate
16:04:56 <roshi> I bet that's hell on upholstery
16:05:29 <tflink> ok, I think we have pretty much everyone I was expecting and expressed interest via IRC or email, so let's get started
16:05:40 <tflink> before we lose any chairs or couches
16:06:01 <tflink> and before I forget
16:06:10 <handsome_pirate> lol
16:06:16 <tflink> #chair kparal jskladan
16:06:16 <zodbot> Current chairs: jskladan kparal tflink
16:06:34 <tflink> #topic Current Project Status
16:07:07 <tflink> We have several devel projects which have either been discussed or worked on recently
16:07:35 <tflink> I'd like to take a few minutes to go over a brief status and if there are short term plans for them
16:08:06 <tflink> mkrizek wasn't able to make it today, so I'll be doing the blockerbugs status
16:08:54 <tflink> #info Not much is going on with blockerbugs for the short term - we're waiting to see how f21 and/or fedora.next shape out before working on any new features beyond the small changes ready for review
16:09:26 <Viking-Ice> which features are in the queue ?
16:10:07 <tflink> voting in-app, being able to view previous blockers are the ones that I can think of off the top of my head
16:11:08 <handsome_pirate> Both useful features
16:11:18 <tflink> the voting feature never got filed, but the others are filed in phabricator
16:11:22 <tflink> https://phab.qadevel.cloud.fedoraproject.org/project/view/1/
16:11:45 <Viking-Ice> voting in app ?
16:11:52 <Viking-Ice> for out of meeting votes or?
16:12:05 <tflink> Viking-Ice: yeah, supporting async voting w/o cruft-ifying bugzilla
16:12:14 <tflink> voting and comments
16:12:30 <tflink> so that folks can participate in the blocker discussions without having to be available for the meetings
16:12:43 <handsome_pirate> Good idea, I think
16:13:06 <Viking-Ice> why not then take the whole step and just skip blocker bug meetings altogether and just have final day to cast votes instead?
16:13:40 <tflink> but since we have no idea what's going on with f.n, there's little point in adding features until we have a better idea of how blockers will work
16:13:50 <handsome_pirate> Viking-Ice:  Because all our attepts to get voting to happen outside of meetings so far has not worked well
16:14:05 <Viking-Ice> tflink, I would think that would be irrelevant
16:14:06 <tflink> Viking-Ice: because there will always be contriversial bugs and ones that could benefit from real-time discussion
16:14:08 <kparal> Viking-Ice: I think that can be up to discussion when we have to tool ready and tested
16:14:40 <tflink> the idea is to include folks who can't make it to the review meetings and reduce the length of those meetings
16:14:43 <Viking-Ice> tflink, as in having to wait for fedora.next there are several maintainers that are just ignoring it altogether
16:14:56 <Viking-Ice> ( that I'm aware of )
16:16:29 <tflink> Viking-Ice: you're welcome to take up some feature development if you'd like. mkrizek and I are planning to hold off until we know what changes will be required for f.n
16:16:33 <Viking-Ice> in otherwords we should just continue on the track that we have been on or expect just be handling base
16:16:47 <tflink> we have a couple of months
16:16:59 <tflink> and there's no shortage of stuff to do with taskotron
16:17:05 <Viking-Ice> ok
16:18:05 <tflink> there are also some devops-ish things that we wanted to do with blockerbugs
16:18:12 * tflink is re-reading an email from mkrizek
16:18:31 <tflink> ie, auto deployment of blockerbugs to dev on code change and auto build/deploy of docs
16:18:32 * Viking-Ice throws up with the mentioning of devops
16:18:43 * tflink doesn't have a better term for it
16:18:57 <tflink> anyhow, I think that's it for blockerbugs
16:19:16 <tflink> jskladan: can you do a quick update on resultsdb and testdays?
16:19:33 <tflink> #topic Current Status and Plans - resultsdb and testdays
16:19:39 <jskladan> tflink: Sure thing
16:20:47 * mkrizek joins
16:20:59 <tflink> mkrizek: you just missed the blockerbugs status :)
16:21:13 <mkrizek> :/
16:21:23 <jskladan> Ad Resultsdb: the "bare" resultsdb implementation is (for some time already) running at <http://resultsdb.qa.fedoraproject.org/resultsdb> and you can browse the results here <http://resultsdb.qa.fedoraproject.org/resultsdb_frontend/>
16:21:27 <mkrizek> will read the logs
16:21:46 <jskladan> it currently implements API described here: http://docs.resultsdb.apiary.io/
16:21:57 <tflink> #info the reduced re-implementation for resultsdb is up and running at http://resultsdb.qa.fedoraproject.org/resultsdb
16:22:11 <jskladan> and should be capable of the same tasks as the "old" one was (AFAIK)
16:22:22 <tflink> #info resultsdb browsing is available at: http://resultsdb.qa.fedoraproject.org/resultsdb_frontend/
16:22:45 <tflink> #info resultsdb API docs are at: http://docs.resultsdb.apiary.io/
16:22:52 <Viking-Ice> any docs for test case writing?
16:23:17 <tflink> Viking-Ice: test case writing? as in automated or manual?
16:23:26 <Viking-Ice> both
16:23:49 <tflink> not really, no. I'm planning to cover that w/ taskotron, though
16:24:01 <Viking-Ice> ok
16:24:08 <jskladan> Viking-Ice: none so far, there is no reason to create docs for AutoQA, and I'll create some examples for Taskotron (in time)
16:24:35 <jskladan> Viking-Ice: But I can easily create a "sample" script describing the basic reporting workflow
16:25:10 <Viking-Ice> that would be helpful
16:25:37 <tflink> jskladan: can you do a brief summary of what the new resultsdb is and why it changed?
16:25:51 <tflink> I don't think that we've ever documented that outside of our discussions at flock
16:27:25 <jskladan> OK, so the new resultsdb is (comparing to the old concept) quite simplified on the data level - we stripped all the un-used tables from the old concept, and adapted the data to what we actually used with the autoqa reporting
16:27:46 <jskladan> while the resultsdb still keeps the ability to store "any" result
16:28:05 <jskladan> meaning that the required fields are not autoqa/taskotron-centric
16:28:11 <tflink> #info the new resultsdb is (comparing to the old concept) quite simplified on the data level - we stripped all the un-used tables from the old concept, and adapted the data to what we actually used with the autoqa reporting
16:28:38 <jskladan> (probably best-shown by the schema: <https://fedoraproject.org/wiki/AutoQA_resultsdb_schema>
16:29:18 <tflink> #info old and new resultsdb schema displayed at: https://fedoraproject.org/wiki/AutoQA_resultsdb_schema
16:29:28 <jskladan> Also, the API has changed, the most visible change is switching from XMLRPC to RESTful API
16:29:56 <jskladan> in order to use the same technologies through our tools (taskotron, resultsdb, ...)
16:30:30 <tflink> yeah, going forward - all the qa web tools will speak restful json
16:31:07 <tflink> jskladan: anything else you can think of for resultsdb?
16:31:15 <jskladan> that's about it for ResultsDB, I guess
16:31:42 <tflink> in retrospect, I probably should have done one topic per project
16:31:43 <Viking-Ice> so here's a dumb question about "needs inspection" and "waived"  dont you need to inspect why things got waived in the first place
16:31:59 <tflink> Viking-Ice: waived is a manual process
16:32:12 <tflink> it has to be done by a person, so it would already be inspected at that point
16:32:32 <tflink> "needs inspection" indicates that something didn't quite go right but that wasn't enough to fail or crash
16:33:07 <Viking-Ice> tflink, I would think one should never waive in the first place but fix what triggered the I assume here false negative
16:33:45 <tflink> Viking-Ice: in an ideal world, maybe. however, there will always be corner cases and problems with the checks that cause false negatives
16:34:24 <tflink> if we're serious about gating builds/updates based on automated checks, we're going to need to have a mechanism for saying "no computer, this isn't a failure"
16:34:37 <Viking-Ice> but those should be treated as real errors from my pov but anyway carry on
16:34:58 <kparal> Viking-Ice: sometimes we need to waive soon and the fix will take time
16:35:06 <jskladan> Viking-Ice: Also - before the Waiving gets implemented, some authorization/authentication/user roles will need to get implemented (in order to keep track of who did what)
16:35:18 <Viking-Ice> right
16:35:21 <tflink> which will be fas
16:35:53 <tflink> but we can get into more of the "what groups and how to get membership" once we get closer to implementation
16:36:08 <tflink> anything else for resultsdb?
16:36:10 * Viking-Ice still scratches head why we aren't using 389ds as the backend for user data
16:36:54 <tflink> ok, moving on since we're already 36 minutes in
16:37:01 <tflink> #topic Current Status - testdays
16:37:33 <tflink> I couldn't think of a better name but I assume everyone knows what I'm referring to?
16:37:45 <jskladan> TestdayApp maybe?
16:37:50 <tflink> yeah
16:38:00 <tflink> oh, a suggestion
16:38:04 <tflink> whoops
16:38:06 <tflink> #undo
16:38:06 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x2f9fc2d0>
16:38:15 <tflink> #topic Current Status - Testday App
16:39:31 <Viking-Ice> which would solve what?
16:39:31 <Viking-Ice> if the world is automated do we need test days?
16:39:44 <jskladan> Ad testdays app: the testdays app is IMHO quite self-confined, and I have no immediate goals for changing what it does (apart of bug-fixes). This is because it's using  the 'old' resultsdb, and uses TurboGears2
16:39:54 <tflink> Viking-Ice: i don't think anyone here thinks taht everything can be automated
16:39:55 <Viking-Ice> ( since we tell users to do a, b and c when testing on test days )
16:40:28 <tflink> #info the testdays app is IMHO quite self-confined, and I have no immediate goals for changing what it does (apart of bug-fixes). This is because it's using  the 'old' resultsdb, and uses TurboGears2
16:41:34 <jskladan> The plans for the future are to re-write it with Flask & New Resultsdb
16:42:13 <jskladan> but it is (at the moment) quite low-priority
16:42:29 <tflink> #info The plans for the future are to re-write it with Flask & New Resultsdb but it is (at the moment) quite low-priority
16:42:45 <tflink> anything else on the testdays app?
16:42:50 <kparal> I think it would be best to spend our time on real automation rather then further developing this app. it serves the purpose right now
16:43:03 <tflink> agreed
16:43:08 <jskladan> ack
16:43:09 <tflink> we have limited people and time
16:43:17 <jskladan> all from me on the TestdayApp
16:43:24 <tflink> ok, moving on
16:43:31 <tflink> #topic Current Status - Support Tools
16:43:47 <tflink> I've been working on this for a while and it's getting close to being done for now
16:43:57 <Viking-Ice> tflink,  I know that we know that it's not enough but you know the rest thinks birds and feathers
16:44:18 <handsome_pirate> tflink:  What is 'this'?
16:44:27 <tflink> handsome_pirate: support tools
16:44:36 * tflink is going to get into more detail
16:44:44 <Viking-Ice> hmm right perhaps since this is the first meeting explain each item being discussed
16:44:46 <tflink> Viking-Ice: yeah, that's going to be an interesting discussion
16:45:15 * tflink goes back in time and learns to type faster :-P
16:45:41 <tflink> This section is the tools that I've been working to deploy over the last several months
16:46:01 <tflink> phabricator (code review, issue tracking etc.) and buildbot/jenkins for ci
16:46:05 <tflink> are the primary parts
16:46:19 <Viking-Ice> I have minions to type for me
16:46:22 <tflink> bah, moar #infos
16:47:03 <tflink> #info the main support tools that we have are phabricator (code review, issue tracking etc.) and buildbot (in progress)/ jenkins (existing, not quite working) for ci
16:47:22 <tflink> #info phabricator is deployed at https://phab.qadevel.cloud.fedoraproject.org/
16:47:39 <handsome_pirate> Ah
16:47:46 <Viking-Ice> http://phabricator.org/
16:47:51 <tflink> logins are still local, waiting on persona provider support in FAS which should be deployed to staging this week
16:48:41 <tflink> it's not perfect, but it does seem to be working and I've yet to find a better overall tool for code reviews and issue tracking
16:49:01 <tflink> #action tflink to write up docs on code review with phabricator
16:49:32 <tflink> the feedback I've gotten thus far has been mostly positive - it's better than trac+reviewboard, anyways
16:49:55 <tflink> CI is a bit of a mess ATM
16:50:10 <tflink> the only project with CI right now is blockerbugs
16:50:46 <tflink> and that has been happily passing on jenkins for a long time ... because the build process is improperly configured and the failures aren't being detected by jenkins
16:51:11 <tflink> Since we're using buildbot for taskotron, I figured it would make more sense to use that instead of jenkins for qa project CI
16:51:31 <tflink> I've deployed buildbot to qadevel-stg, but it's not complete yet
16:51:59 <tflink> #info buildbot for qa project CI is deployed to staging at https://qadevel-stg.cloud.fedoraproject.org/builds/
16:52:32 <handsome_pirate> tflink:  Any way I could get access to that?
16:52:48 <handsome_pirate> tflink:  /me would like to check out how you deployed it
16:52:52 <tflink> qadevel will need to be rebuilt as a fedora machine, but with the backups and ansible scripts I don't think that'll mean any more than an hour or two of downtime
16:53:11 <tflink> handsome_pirate: if I haven't pushed the playbooks to bitbucket, I need to
16:53:20 <handsome_pirate> tflink:  Roger
16:53:31 <handsome_pirate> tflink:  That would be useful for setting up local devel instances
16:53:53 <tflink> long story short - deploying buildbot on el6 w/ epel compliant packages is ... difficult at best
16:54:07 <Viking-Ice> so one questions with all work on these test and automation in place will the result if failure be hard failure or soft failure ( hard failure means maintainers needs to react soft failure maintainer is just notified )
16:54:16 <Viking-Ice> tflink, we should be deploying on Fedora in our infra ;)
16:54:23 <tflink> Viking-Ice: also true
16:54:36 <tflink> to the fedora part - I'm not all that upset about it
16:55:01 <mkrizek> deploying to fedora is easier than el6 in general, so +1
16:55:30 <tflink> a little dismayed on how much of a PITA deploying buildbot to el6 is with packages, but short of building new scls, it isn't going to happen
16:55:45 <tflink> but I digress
16:56:41 <tflink> #info there is still work to do on buildbot so that we have CI and hopefully autogenerated docs for qa devel projects
16:56:50 <tflink> #undo
16:56:50 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x2f2b6290>
16:56:57 <tflink> #info there is still work to do on buildbot so that we have CI and hopefully autogenerated and autodeployed docs for qa devel projects
16:57:08 <tflink> dang, we're already at an hour
16:57:23 <tflink> any other questions on support tools?
16:57:41 <Viking-Ice> not from me btw did you book a two hour meeting for this?
16:57:56 <tflink> Viking-Ice: yep, but I was hoping to get done wiht statuses within 30 minutes
16:58:16 <tflink> there is still a lot of taskotron stuff to cover :-/
16:58:17 <Viking-Ice> hopes and actuality  ;)
16:59:03 <tflink> it sounds like we're all pretty much on the same page WRT priority (ie, getting automation done while we have the break)
16:59:38 <tflink> I was going to suggest skipping that part and grouping all the taskotron stuff together
16:59:51 <tflink> but I think it would be good to have in the minutes
17:00:05 <tflink> any objections to delaying taskotron status until after "priorities"?
17:00:23 <jskladan> none
17:00:26 <Viking-Ice> nope
17:00:36 <tflink> #topic Priorities
17:01:48 <tflink> This was mentioned before, but for the sake of recording it - we have lots of projects to work on and we have a rare break between releases to work on improving our tooling
17:02:09 <Viking-Ice> as well as focusing on our community I might add
17:02:42 <tflink> in my mind, getting taskotron deployed and working in an initial stage is our highest devel priority since it's a large project and is rather disruptive
17:03:04 <mkrizek> +1
17:03:04 <tflink> Viking-Ice: true, I'm not trying to exclude that
17:03:11 <kparal> should we include beaker into the mix?
17:03:20 <tflink> good question
17:03:31 <tflink> that's gotten more attention than I was originally expecting
17:03:47 <tflink> I was hoping to put that off until after we get the initial taskotron deployment done
17:03:57 <kparal> I think it can bring large benefits with small time investments
17:04:04 <handsome_pirate> tflink:  It would be nice for folks in, say, the QA fas group to be able to spin up beaker instances to test Fedora
17:04:29 <tflink> I'm not sure I see any small investments outside of getting FAS integration, though
17:04:43 <tflink> handsome_pirate: that is anything but a trivial task, unfortunately
17:05:08 <tflink> and I'm not even sure that's a use case that would benefit us much
17:05:41 <kparal> well, if we make sure the tasks run correctly and also do something about reporting (get notifications about failures, display the status), we can have at least basic anaconda automation easily
17:05:42 <Viking-Ice> which brings up an interesting question how easy it is for testers to deploy all that's being worked on locally @home or @dayjob etc
17:05:45 * mkrizek needs to leave, again :/
17:06:15 <tflink> Viking-Ice: depends on what you're including in that
17:07:27 <tflink> kparal: the concern I have is with security and containing the clients
17:07:43 <kparal> tflink: I wasn't proposing to open the instance to public
17:08:01 <tflink> ah, I assumed that was part of displaying the statuses
17:08:10 <tflink> the current instance does work, AFAIK
17:08:14 <kparal> the smallest scope available is just to set up reporting and notifications and have someone trusted execute a test run on every new TC
17:08:18 <tflink> it's just not all that public
17:08:38 <kparal> it would be nice to at least make the results public
17:08:43 <kparal> export to a wiki page or something
17:09:11 <Viking-Ice> tflink, basically everything I would think, ( think deployments with rpmfusion, russian fedora, remixes and locally )
17:09:28 <tflink> Viking-Ice: the plan is to have everything configured with ansible playbooks
17:09:48 <tflink> some bits are going to be, by definition, non-trivial to deploy but I want to make it as painless to replicate as possible
17:09:50 <kparal> I think our beaker needs some finishing touches to be at least basically useful, that's all.
17:10:15 <tflink> kparal: agreed, I'm just wondering how much work that would entail
17:10:54 <Viking-Ice> tflink, I'm thinking taking the system which is being written and deployed elsewhere like if I want to write code or test cases I would like to test it locally before pushing it into Fedora
17:11:11 <kparal> unfortunately I don't have a clear idea. in think it should be quite easy
17:11:22 <tflink> Viking-Ice: sure, but those are two separate things in my mind
17:11:28 <Viking-Ice> ok
17:11:44 <tflink> but either way, we're getting a bit off topic for the moment
17:12:21 <kparal> so, one person finishing beaker (possibly with atodorov) and the rest working on taskotron?
17:13:04 <tflink> proposed #agreed As we have a longer break between releases for now, automation is a higher priority because it is more disruptive and needs to be done soon
17:13:16 <tflink> kparal: I'm not even sure I'd want to have one person working on beaker right now
17:13:30 <tflink> full-time, anyways
17:13:50 <tflink> ack/nak/patch?
17:13:53 <handsome_pirate> tflink:  ack
17:14:02 <Viking-Ice> ack
17:14:17 <kparal> my thinking was that we could teach twu and lili to operate beaker and manage it
17:14:41 <kparal> because I think they don't program too much, so this could be easier for them
17:14:48 <tflink> kparal: I'm not sure that's going to be easy, though
17:15:51 <kparal> well, just thinking aloud
17:15:53 <tflink> not that I doubt twu and lili, I just know how everythings setup
17:16:02 <tflink> and it needs to be rebuilt
17:16:17 <tflink> any other thoughts on the proposal?
17:16:21 <kparal> you probably have a better idea how ready our instance is
17:16:32 <kparal> ack
17:16:42 <tflink> #agreed As we have a longer break between releases for now, automation is a higher priority because it is more disruptive and needs to be done soon
17:16:59 <tflink> ok, do we want to talk about beaker quick since that's already started?
17:17:12 <Viking-Ice> yeah sure
17:17:13 <tflink> we only have 45 minutes left, though
17:17:26 <tflink> #topic Fedoraproject Beaker Instance Status
17:17:56 <tflink> so, we have a dev instance of beaker deployed at https://beaker-dev.fedoraproject.org/bkr/
17:18:04 <tflink> bah, #infos
17:18:11 <tflink> #info we have a dev instance of beaker deployed at https://beaker-dev.fedoraproject.org/bkr/
17:18:29 <tflink> #info due to security concerns, it is currently locked down by IP
17:18:45 <tflink> long story short, the auth mechanism in beaker isn't awesome
17:19:03 <tflink> and if you get into the web interface, you can get root access to any of the clients
17:19:10 <Viking-Ice> ou don't have permission to access /bkr/ on this server.
17:19:10 <Viking-Ice> restricted to RH ip's
17:19:36 <tflink> which means that you then have control of machines inside the fedora infra
17:19:51 <tflink> Viking-Ice: RH ips and a few others who have been using the instance
17:19:59 <tflink> not ideal, but I don't really have a better idea
17:20:41 <tflink> until we have FAS integration and the beaker clients locked down more, I'm not all that comfortable opening the instance up
17:21:05 <tflink> if it was just a webapp, I wouldn't be so concerned but it's _not_ just a webapp
17:21:16 <Viking-Ice> the virtual host hook up to fas auth but anyway
17:21:26 <Viking-Ice> but I think it's then best to just wait with beaker speak until people can explore it
17:22:28 <Viking-Ice> here's this thing we are using but you cant access it so perhaps jump to task*
17:22:29 <tflink> Viking-Ice: I see your point, but there are multiple RH groups who want to use the instance to run their test cases and get those test cases open sourced
17:22:31 <kparal> if we keep the instance intact, is it ready for F21 TC1 once they arrive? can one of us who has access just feed it the TC and then explore the results? or something else needs to happen?
17:23:16 <tflink> keeping the instance mostly RH only is not ideal, but I'm having a hard time justifying telling RH folks to go away because the thing isn't ready to be public
17:23:30 <tflink> kparal: mostly, I think
17:23:40 <kparal> tflink: what's missing?
17:23:59 <tflink> I suspect that atodorov will need to tweak the SNAKE stuff some more
17:24:23 <tflink> but from an instance perspective, it's working as long as your IP is "allowed"
17:24:27 <kparal> tflink: do beaker devs do something to improve the auth scheme?
17:24:29 <Viking-Ice> tflink, bit unfair RH has beaker instance internally for itself right
17:25:00 <tflink> Viking-Ice: true, but for various reasons, running fedora tests there isn't all that easy
17:25:52 <tflink> kparal: they say that it should work, but I've yet to be able to get any of it to work with mod_auth_openid
17:25:56 <handsome_pirate> Viking-Ice:  It's very difficult to get TCs and RCs into Beaker on time to do anything useful
17:26:17 <Viking-Ice> well if anyone that has an static IP can request for access thus be on equal term with RH employees it does not matter
17:26:30 <tflink> Viking-Ice: pretty much, yeah
17:26:45 <tflink> If there are people with tests, I'm willing to add IPs
17:27:20 <tflink> but I don't want to start any formality around it - I'd rather spend that time and energy getting things locked down so we don't have to muck around wiht IP restrictions
17:27:21 <Viking-Ice> and to be able to write test you need to know how to write them ;)
17:27:47 <tflink> but we have 30 minutes left and haven't touched the taskotron stuff yet
17:28:21 <tflink> how about kparal and I sync up on beaker status, come up with some ideas and report back at that time?
17:29:01 <tflink> I'm not trying to keep folks out of the discussion, just don't want to spend more time on it right now
17:29:05 <kparal> sure, let's move on
17:29:15 <tflink> #topic Taskotron status
17:29:21 <tflink> er
17:29:23 <tflink> #undo
17:29:23 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x2f159350>
17:29:49 <tflink> #action kparal and tflink to sync up on beaker.fp.o status and come up with some ideas on moving forward
17:29:52 <tflink> #topic Taskotron status
17:30:00 * tflink will try to get through this quickly
17:30:47 <tflink> #info The hope was to have taskotron phase 0 (https://fedoraproject.org/wiki/User:Tflink/taskotron_development_plan#Phase_0:_Investigation_and_Preparation) done by now
17:31:01 <tflink> it is somewhat done
17:31:36 <tflink> #info task description format was proposed and sent out to qa-devel@. response has been mostly positive and it is ready to start moving forward
17:32:27 <tflink> #info initial fedmsg reliability investigation indicates that it will be reliable enough to use for automation scheduling but we should continue to keep an eye on it
17:32:43 <tflink> #link https://phab.qadevel.cloud.fedoraproject.org/T2
17:32:48 <Viking-Ice> User-Submitted Package-Specific Checks has the highest priorities in Phase Z right?
17:33:18 <tflink> Viking-Ice: that's still up for debate, I think
17:33:30 <Viking-Ice> why ?
17:34:06 <tflink> which is more important - automating basic installation checks or user submitted tasks?
17:34:20 <tflink> there are also security issues for user-submitted tasks
17:34:30 <Viking-Ice> granting the ability for maintainers and others to submit package specific test precedes anything else since the rest will be handled by their sub communities
17:34:58 <Viking-Ice> great
17:35:33 <tflink> I'm not saying that user submitted tasks aren't important
17:36:24 <tflink> can we get through current status before getting into stuff that's at least a month or two out, though?
17:36:46 <tflink> user submitted tasks will be worthless without a solid base system to run them on
17:37:21 <Viking-Ice> mean we just focus first on base and installation then rest is handled respectfully by their communites so basically the priority order of test cases is what makes up anaconda then the install then base/core bootup but yeah proceed with current status
17:37:38 <handsome_pirate> tflink:  I'm +1 for moving on
17:37:54 <tflink> #info there was a proof-of-concept system running in the fedora cloud, but it seems to be having issues ATM
17:38:05 * tflink has been meaning to re-deploy for a while now
17:39:18 <tflink> The big remaining task for phase 0 is discussion/investigation into notifications
17:39:25 <tflink> #info The big remaining task for phase 0 is discussion/investigation into notifications
17:39:41 <tflink> I was working on an email to that end yesterday but didn't get it finished
17:40:29 <tflink> #info the proof-of-concept runner does work locally and does produce output to the console, it can't report to resultsdb (yet) and needs some refactoring
17:41:35 <handsome_pirate> It seems that we have autoqa notifications tuned rather well at this point
17:41:44 <tflink> I disagree
17:41:49 <kparal> me too
17:42:00 <tflink> I want to do away with that whole system and most of its concepts
17:42:12 <tflink> but that's a long conversation in itself :)
17:42:16 <handsome_pirate> Ah
17:42:21 <handsome_pirate> Email with that, then
17:42:28 <tflink> #action tflink to finish notificaitons email and send it out to qa-devel@
17:43:37 <tflink> I think that with another day or two of work, we could have a working proof-of-concept system using the task description format, rpmlint and reporting to the new resultsdb
17:45:13 <handsome_pirate> tflink:  What's the next step(s)?
17:45:25 <handsome_pirate> tflink:  Also, how do you want to handle assigning tasks?
17:45:34 <tflink> #info depcheck scenarios have been drafted up and fake rpms have been coded up for testing
17:46:18 <handsome_pirate> tflink:  On that end, I've got a vm set up with old depcheck for comparison
17:47:16 <tflink> bitbucket is slow for me ATM
17:47:26 <tflink> #link https://bitbucket.org/fedoraqa/depcheck_scenarios
17:48:00 <handsome_pirate> Yeah, it is slow
17:48:14 <tflink> I think that's most of the status outside of infra planning
17:48:56 <tflink> it's going to seem like I'm skipping over stuff, but please bear with me for a few minutes - I think that I'll circle around to most questions in a few minutes
17:49:04 <tflink> #topic Deadlines and Milestones
17:49:09 * handsome_pirate will be right back
17:49:25 <tflink> #info Current deadline for taskotron phase 1 is 2013-03-01
17:49:47 <tflink> #link https://fedoraproject.org/wiki/User:Tflink/taskotron_development_plan#Phase_1:_AutoQA_Replacement
17:50:15 <tflink> Phase 1 is pretty much replacing autoqa - no new major functionality, just getting the new system working and in place
17:51:07 <tflink> There are a lot of unknowns in there still, so I'd like to avoid planning out much beyond this initial phase for now
17:51:46 <tflink> I'm _very much_ of the opinion that we need a stable base before we can have useful conversations around how to support user-submitted tasks or anything fancy
17:52:00 <kparal> yes
17:53:15 * jskladan needs to go, see you around tomorrow!
17:53:40 * pschindl has to go to catch a train.
17:53:54 <tflink> do we want to continue this later?
17:54:45 <Viking-Ice> I'm fine either or
17:55:19 <kparal> aren't we out of time anyway?
17:55:23 <tflink> to be 100% clear on the current point, I'm not saying that user-submitted tasks or beaker integration or installation checks aren't important - just that we can't really plan for them well right now and I'd rather focus on what we _can_ fo for the moment
17:55:27 <tflink> yeah
17:55:34 <Viking-Ice> just before finishing I have to ask if these needs to be weekly meetings ( seems like it's not necessary )
17:55:35 <tflink> this took longer than I was hoping
17:55:59 <tflink> #topic Meetings
17:56:00 <kparal> tflink: do you think we can easily engage 5 or more people in taskotron tasks?
17:56:40 <tflink> if people are willing to take a description and figure some of the details out, yes
17:56:40 <kparal> I think we should set up a meeting as we need it
17:56:47 * kparal is not fond of regular meetings
17:56:49 * handsome_pirate is back
17:57:09 <tflink> but it does sound like scheduling something else to continue all this would be wise
17:57:18 <Viking-Ice> kparal, right that's my take on it as well as things stand now things have been priorities discussion takes place on list etc
17:57:27 <tflink> since we didn't get into TODO yet
17:57:37 <handsome_pirate> tflink:  +1 for followup
17:57:46 <tflink> or we can try to do it all on list
17:57:47 <handsome_pirate> tflink:  It may be wise to do it early next week
17:58:07 <kparal> monday after qa meeting then?
17:58:16 <handsome_pirate> also, the start time on Thursday sucks since I have a work meeting at the same time on Thursday
17:58:16 <tflink> works for me
17:58:21 <handsome_pirate> kparal:  +1
17:58:37 <tflink> #action tflink to schedule followup meeting after monday's qa meeting
17:58:53 <tflink> if there's nothing else ...
17:58:57 <tflink> #topic Open Floor
17:59:09 <tflink> Apologies for this taking up so much time
17:59:22 * tflink really thought we'd get farther in 2 hours
17:59:44 <handsome_pirate> tflink:  With this croud? :)
17:59:52 <tflink> anything else that needs to be addressed before monday?
17:59:59 <Viking-Ice> tflink, it's alot of topic to cram into initial meeting
18:00:12 <tflink> yeah, but I can still hope :)
18:00:32 <tflink> on the bright side, this has been a great demonstration on how much I need to de-bus-factor and write docs :)
18:00:58 <Viking-Ice> basically everything being deployets needs to be explained what purpose it serves and what problems it's trying to solve
18:01:22 <Viking-Ice> right ;)
18:01:26 <tflink> yeah, and while I know all that, little of it is written up. and that's a problem
18:01:55 <Viking-Ice> tflink, use the minions or the new guy
18:01:59 * tflink puts up 'no raptors' signs
18:02:23 <handsome_pirate> tflink:  Already have one
18:02:47 <Viking-Ice> btw new guy name can stick on a person for quite some time ( we had one here @dayjob that joined a group 15 years ago and no one has joined the group hence he's still called the new guy )
18:03:15 <Viking-Ice> joined the group since I mean+
18:03:36 <tflink> if there's nothing else, I'll set the fuse
18:04:22 <handsome_pirate> Viking-Ice:  LOL
18:04:46 <handsome_pirate> croberts is the new guy :)
18:04:58 <handsome_pirate> croberts:  You awake over there? :)
18:05:10 <croberts> hey :)
18:05:14 <croberts> yep I am new to testing
18:05:34 <croberts> handsome_pirate is helping me out
18:05:41 <croberts> i know roshi from marketing
18:06:28 <tflink> 3 ... 2 ... 1 ...
18:06:32 <tflink> boom!
18:06:37 * tflink will send out minutes shortly
18:06:41 <tflink> Thanks for coming everyone!
18:06:44 <tflink> #endmeeting