14:00:54 <tflink> #startmeeting fedora-qadevel
14:00:54 <zodbot> Meeting started Mon Mar 13 14:00:54 2017 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:54 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:00:54 <zodbot> The meeting name has been set to 'fedora-qadevel'
14:01:03 <tflink> #topic roll call
14:01:08 * mkrizek 
14:01:23 * tflink was following UTC thinking he sent out the wrong meeting time and is a little unprepared
14:01:32 * roshi 
14:01:37 <tflink> cursing DST for the next couple minutes is encouraged
14:01:39 * jskladan joins for the fun parts
14:02:14 <jskladan> all hail UTC!
14:02:41 <jskladan> (also the DST change for us back in Brno is in two weeks...
14:02:52 <tflink> I thought it was 3 weeks
14:03:00 <tflink> either way, all hail UTC!
14:03:38 * roshi is on the UTC bandwagon
14:03:45 <tflink> #topic Announcements and Information
14:04:13 <tflink> this isn't in a wiki page this week, so please list the things that you would have normally put there
14:04:33 <mkrizek> #info taskotron-dev works again - mkrizek
14:05:07 <mkrizek> #info deployment of atomic/cloud checks is in progress - mkrizek, roshi
14:05:14 <roshi> ^^
14:05:52 <mkrizek> #info we have nested virt on dev \o/
14:06:16 <tflink> cool, qa11 has been rebooted now?
14:06:21 <mkrizek> yep
14:06:42 * kparal is late
14:06:47 <roshi> #info working on overview documentation for how data flows through taskotron - roshi
14:06:49 <tflink> do we have the change ready for the other qa boxen?
14:06:54 * tenk is late
14:07:26 <mkrizek> for all client-hosts yes, just run the playbook and reboot
14:07:42 <tflink> cool
14:08:14 <tflink> anything else?
14:08:24 <mkrizek> nothing else here
14:08:35 * tflink was in meetings pretty much all of last week, didn't get much of anything productive done
14:08:47 <tflink> #info phab updated to a version with working search
14:08:52 <tflink> other than that, forgot about that
14:08:58 <kparal> tflink++
14:09:06 <tflink> but moving on
14:09:08 <kparal> also mkrizek++
14:09:08 <zodbot> kparal: Karma for mkrizek changed to 1 (for the f25 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
14:09:33 <tflink> #topic Deploying New Features
14:09:50 <tflink> specifically, I'm thinking of two: dist-git tasks and the atomic/cloud stuff
14:10:02 <tflink> I'd like to get those into prod by the end of the week
14:10:23 <mkrizek> atomic/cloud stuff seems doable
14:10:42 <tflink> do you have concerns about the dist-git stuff?
14:10:43 <mkrizek> there are couple issues but nothing major I'd say
14:10:58 * roshi is working on a patch for atomic/cloud stuff right now
14:10:59 <mkrizek> that dist-git stuff that runs in stg?
14:11:08 <tflink> yeah
14:11:21 * roshi guesses he'll do the image finding the correct way (that we talked about in #D1157)
14:11:24 <mkrizek> haven't really checked the results yet
14:11:29 <tflink> potentially for modules and layered images as well
14:11:40 <tflink> since those are in prod koji now
14:11:43 <mkrizek> but if that works well in stg, no objections
14:12:23 <tflink> as far as I know, it works well in stg other than me adding an 's' to the documentation (tests directory instead of test)
14:13:37 <mkrizek> is everything needed in develop?
14:13:54 <tflink> as far as I know, yes
14:14:13 <mkrizek> cool
14:14:15 <tflink> I'm pretty sure that all the required patches landed last week and they may already be released
14:14:54 <mkrizek> we'll need a new trigger for atomic/cloud stuff though
14:15:17 <mkrizek> for the issue we discovered today
14:15:23 <tflink> ah
14:15:40 <tflink> I was going to ask how that wasn't covered by roshi's patch
14:17:04 <tflink> any more questions/concerns/comments about this?
14:17:28 <mkrizek> none here
14:17:59 * tflink moves to the next topic
14:18:11 <tflink> #topic Documentation, Guides and Examples
14:18:34 <tflink> I expect a lot of new people to start writing tasks once we get the dist-git stuff deployed
14:19:25 <tflink> I don't recall exactly who it was right now (I blame still being a bit sick) but I have some notes on issues that folks had in our documentation
14:19:37 <tflink> they were brought up last week
14:19:56 <kparal> maxamillion
14:20:01 <kparal> iirc
14:20:05 <tflink> oh yeah, thanks
14:20:38 <kparal> are we going to go with full formula etc needed, or are we going to try to have some simplified wrapper asap (only requiring folks to write a bash script, we do everything else)?
14:21:00 <tflink> if we want the dist-git stuff to be successful, our docs need to be easy to follow and we need to have some more examples
14:22:15 <tflink> I'm not sure how realistic it is to have that wrapper ready asap
14:22:22 <tflink> s/asap/this week
14:22:27 <roshi> yeah, I talked to adam (maxamillion) a bit about it
14:22:53 <roshi> and I'm writing a high-level overview that shows how data moves from fedmsg through taskotron ending in a resultsdb submission
14:23:07 * tflink thinks that the stuff roshi's working on will help
14:23:19 <roshi> so if you're looking at any part of the system, you can have a better grasp of what bits have what inputs and what outputs
14:23:57 <tflink> that does seem to be a thing that folks get hung up on - where the vars come from, what they're named and what's in them
14:25:22 <roshi> it threw me for a bit
14:25:33 <tflink> I know I've had this as a meeting item for the last several meetings but if you get the chance, please go through our docs and see if there's anything that's out of date
14:25:40 <roshi> which also makes the "install libtaskotron locally and run these args
14:25:47 <roshi> " seem kinda arcane
14:26:12 <tflink> roshi: not sure I follow
14:26:58 <roshi> not knowing where the vars come from
14:27:21 <roshi> when I was writing a task for the first time, the -i -t flags for runtask were really unclear to me
14:27:28 <tflink> ah
14:27:29 <roshi> and how I get info into my task
14:27:39 <roshi> because I had no idea of the bigger whole of the system
14:27:39 <tflink> the doc you're working on should help clarify that, right?
14:27:44 <roshi> that's the goal
14:27:56 <roshi> I'll have maxamillion take a look when it's closer to being done
14:28:06 <tflink> sounds good
14:28:11 <tflink> thoughts on ETA?
14:28:11 <roshi> see if it does what I hope it should
14:28:27 <roshi> as soon as we get this trigger update in
14:28:35 <tflink> ok
14:28:48 <roshi> I'll have a patch in for that today, and I'll be actually parsing the metadata from a compose instead of hardcoding the value
14:29:09 <roshi> it'll be published by the end of the week
14:29:27 <tflink> roshi: thanks
14:29:29 <tflink> roshi++
14:29:29 <zodbot> tflink: Karma for roshi changed to 7 (for the f25 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
14:29:43 <tflink> anything else on this?
14:29:58 <jskladan> nope
14:31:19 <tflink> so, moving on to everyone's favorite topic ...
14:31:25 <tflink> #topic Phabricator
14:31:57 <tflink> I'd like to make a decision on what we're going to be doing long term
14:32:29 <tflink> there has been yet another php package added which will need to be shepherded if we want to have real packages
14:33:22 <tflink> https://bugzilla.redhat.com/show_bug.cgi?id=1418940
14:33:34 <roshi> how hard would it be to just be really lazy and run it in docker?
14:33:41 <tflink> in infra?
14:33:49 <tflink> I don't think that'll fly
14:33:51 <roshi> yeah, can we do that?
14:34:03 <kparal> if there's no one else who'd be interested in having it packaged, I think we should stop spending time on packaging and deploy it per upstream instructions somewhere privately (fedora cloud?), provided we're allowed to do so
14:34:11 * roshi has been wondering if we dogfood atomic/docker in any of our infra
14:34:26 <tflink> we just got the first containers earlier this year
14:35:17 <tflink> kparal: from what I've been told, they don't care as much if it's not production but stuff that doesn't go through koji should be outside infra
14:35:20 <roshi> just a thought, I don't know how tenable it would be
14:35:21 <jskladan> infra hates docker, with grave passion, AFAIK
14:35:45 <kparal> does that mean outside of fedora cloud as well?
14:35:48 <tflink> nope
14:36:10 <kparal> is there any disadvantage in using fedora cloud for phab?
14:36:20 <kparal> except we might need to change the url again?
14:36:22 <tflink> we'd have to change domain names again
14:36:39 <kparal> that would be still worth it I think
14:36:39 <tflink> we'd be 100% responsible for maintaining the instance
14:37:02 <roshi> how many percent responsible were we before?
14:37:04 <kparal> what's the recommended way upstream phab recommends? docker?
14:37:06 <roshi> er, now
14:37:16 <tflink> another issue is that I'm not sure that relying solely on me to keep that instance running is wise long term
14:37:20 <tflink> kparal: via git
14:37:39 <tflink> roshi: ~80%
14:37:40 <kparal> and then what, make install into the system?
14:37:56 <tflink> kparal: no, just run the php application from those checkouts
14:38:19 <tflink> all binaries are run with commands like ./bin/storage
14:38:38 <kparal> ok, so we can run it on a standard fedora, or atomic host
14:38:51 <tflink> standard fedora will likely be easier
14:39:14 <tflink> using kanarip's packages in copr is a pretty easy process
14:39:56 <kparal> I see one major disadvantage here. if we abort our packaging efforts, it will get harder to get involved in developed, due to arcanist
14:40:04 <tflink> another question is if phab is really enough better than pagure to justify this effort going forward
14:40:07 <kparal> not being in fedora proper
14:40:22 <kparal> *development
14:40:31 <tflink> especially when it will likely cause problems with dogfooding
14:41:37 <tflink> kparal: development of the packages or upstream?
14:42:15 <kparal> contributing to taskotron
14:42:34 <tflink> true
14:42:35 * roshi already wrote a container and some bash to let you run arcanist from a container and not have to have arcanist installed locally
14:42:45 <kparal> because while it is possible to upload a diff from the website, using arcanist is far superior
14:42:52 <tflink> but I think that not using a PR based workflow does most of that damage
14:43:21 <kparal> roshi: does it properly integrate with running the test suite of the project, using its virtualenv etc?
14:43:36 <roshi> doesn't run a virtualenv, but it does run the tests and linter
14:43:51 <roshi> since a container kinda is a virtualenv, I didn't see the point in that
14:44:03 <kparal> all my deps are in virtualenv, usually
14:44:10 <kparal> so without it i can't run the test suite
14:44:24 <roshi> for this, all the deps are in your container
14:44:29 <kparal> ah
14:44:37 <roshi> I can do a writeup if people are interested
14:44:49 <roshi> I just did it because I didn't want PHP installed on my machines :p
14:44:51 <kparal> let's see if we keep phab first
14:45:03 <tflink> I think this comes down to a couple of questions
14:45:20 <tflink> 1. Do we want to continue paying the cost of maintaining our own bug tracker and review system?
14:45:28 <kparal> honestly pagure is quite bad atm I think. github is much better. but we can hope for fast improvements in pagure
14:45:44 <tflink> 2. Can we justify being different from everyone else in terms of barriers to new contributors?
14:46:23 <tflink> 3. Who's going to be maintaining our phabricator instance if we get through 1 and 2?
14:46:53 <kparal> do you already know you won't be able or willing to do that in the future, if we keep it in some form?
14:47:13 <roshi> even if he can, we should spread it around
14:47:19 <roshi> busfactor--
14:47:40 <tflink> kparal: maintaining the phab instance? I just have suspicions that make it more risky to rely on me for that going forward
14:47:56 <tflink> particularly only on me
14:48:22 <kparal> do you have some estimate how time consuming it would be if we relied to git checkout deployment?
14:48:30 <kparal> *on
14:49:47 <tflink> in theory, it should be pretty painless outside of keeping the machine updated and updating to the latest stable branch on a regular basis
14:50:22 <roshi> I like the idea of a container model for a one-off like this because it's easy to rollback
14:50:37 <roshi> but I suppose it's easy enough to roll back to a prior commit too
14:51:05 <tflink> the only thing that could be a problem is rolling back the git checkout after running db migrations
14:51:12 * tflink isn't sure how well phabricator would tolerate that
14:51:28 <roshi> yeah
14:51:32 * roshi doesn't know
14:52:03 * roshi doesn't have a real solid preference to one system over the other
14:52:16 <tflink> we only have 9 minutes left so I think this will become a mailing list discussion
14:52:24 <roshi> if we did move to pagure, at least it's python and we could send patches
14:52:33 <tflink> unless folks are ready to take a vote on the various questions
14:53:14 <kparal> I don't know, honestly. all the choices are bad
14:53:19 <tflink> agreed
14:53:36 <tflink> mailing list it is, then :)
14:53:40 <tflink> moving on to ...
14:54:06 <tflink> #action tflink to move the conversation around phab and pagure to qadevel@
14:54:10 <tflink> #topic open floor
14:54:22 <tflink> anything else that folks want to bring up?
14:54:41 <kparal> nothing here
14:54:49 <mkrizek> nothing here
14:55:03 * roshi has nothing
14:55:34 <tflink> then I'll end the meeting and we can reconvene in about 5 minutes for the qa meeting
14:55:39 * tflink will send out minutes shortly
14:55:46 <tflink> thanks for coming, everyone!
14:55:49 <tflink> #endmeeting