18:00:19 <nirik> #startmeeting Infrastructure (2017-02-09)
18:00:19 <zodbot> Meeting started Thu Feb  9 18:00:19 2017 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:19 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:19 <zodbot> The meeting name has been set to 'infrastructure_(2017-02-09)'
18:00:19 <nirik> #meetingname infrastructure
18:00:19 <zodbot> The meeting name has been set to 'infrastructure'
18:00:19 <nirik> #topic aloha
18:00:20 <nirik> #chair smooge relrod nirik abadger1999 lmacken dgilmore threebean pingou puiterwijk pbrobinson
18:00:20 <zodbot> Current chairs: abadger1999 dgilmore lmacken nirik pbrobinson pingou puiterwijk relrod smooge threebean
18:00:20 <nirik> #topic New folks introductions
18:00:24 <clime> hey
18:00:25 <nirik> morning everyone
18:00:28 <athos> hi
18:00:32 <marc84> hi
18:00:54 <cverna> .himynameis cverna
18:00:55 <zodbot> cverna: cverna 'Slim Shady' <cverna@tutanota.com>
18:01:03 * pingou here
18:01:04 <jcline> .hello jcline
18:01:05 <zodbot> jcline: jcline 'Jeremy Cline' <jeremy@jcline.org>
18:01:14 * doteast here
18:01:54 <puiterwijk> Hello
18:02:02 <threenodedev> here
18:02:19 <nirik> any new folks like to give a short oneline intro?
18:03:07 <nirik> alrighty, then lets dive on in...
18:03:25 <nirik> #topic announcements and information
18:03:25 <nirik> #info bodhi-2.4.0 beta deployed to stg, please test! - bowlofeggs
18:03:25 <nirik> #info first mirrorlist container is in production now on proxy02 - kevin/patrick
18:03:25 <nirik> #info mass rebuild hasn't yet started, but should be soon - releng folks
18:03:25 <nirik> #info work on new nagios resumes
18:03:36 <nirik> any other announcements or info?
18:04:06 <pingou> I'm going to try to update our dist-git stg pagure instance
18:04:08 <pingou> once 2.12 is out
18:04:11 <sayan> .hello sayanchowdhury
18:04:12 <zodbot> sayan: sayanchowdhury 'Sayan Chowdhury' <sayan.chowdhury2012@gmail.com>
18:04:16 <jcline> #info new anitya in prod sometime in the next week
18:04:38 <nirik> pingou: cool. ;)
18:04:53 <pingou> :)
18:05:00 <sayan> #info migration of badges from fedorahostted to staging pagure done
18:05:01 <nirik> jcline: did the new newhotness go to prod?
18:05:22 <pingou> sayan: oh, sweet!
18:05:27 <jcline> nirik, not yet, first there was some logging configuration issues, then some dist-git url config issues which I fixed this morning
18:05:48 <nirik> sayan: really? wow. Great news.
18:05:51 <nirik> sayan++
18:05:52 <zodbot> nirik: Karma for sayanchowdhury changed to 12 (for the f25 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:06:01 <jcline> If things look happy in staging tomorrow I'll upgrade it in prod
18:06:18 <cverna> sayan++
18:06:18 <zodbot> cverna: Karma for sayanchowdhury changed to 13 (for the f25 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:06:30 <sayan> nirik: pingou: we are deciding on the tags now should be done by next week i hope
18:06:32 <pingou> sayan++
18:06:40 <pingou> :fireworks:
18:06:46 <cverna> cookies :)
18:06:48 <nirik> jcline: ok. Sounds good.
18:06:53 <sayan> coookies :)
18:07:01 <clime> It would be nice to see the features in some demo
18:07:02 <vivek_> sayan++
18:07:05 <nirik> #info new newhotness update soon if stg looks good.
18:07:34 <sayan> cverna++ vivek_++ for helping on the migration
18:07:34 <zodbot> sayan: Karma for cverna changed to 5 (for the f25 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:07:37 <zodbot> sayan: Karma for vivekanand1101 changed to 5 (for the f25 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:07:59 <pingou> clime: features or? the-new-hotness/anitya? pagure?
18:08:00 <nirik> sounds like a good team effort. ;)
18:08:03 <pingou> s/or/of/
18:08:16 * pingou migrated a few of his projects
18:08:25 <cverna> pingou++
18:08:29 <clime> pagure's features for the badges repo :)
18:08:38 <pingou> we'll need some sort of script to go through all the projects on fedorahosted and see if they are on pagure
18:08:51 <pingou> then we can see which moved elsewhere and then which are left
18:09:01 <clime> I mean, it seems to be quite an achievement to do that migration
18:09:25 <nirik> pingou: yeah, it's hard. Lots of projects also moved other places... some of them didn't really update hosted, they just moved and left it there.
18:09:39 <nirik> so I think it's going to be somewhat manual.
18:10:06 <nirik> also I am 100% sure we will get people for at least the first months asking us where their project went when we take hosted down. ;)
18:10:20 <cverna> nirik: you did a wiki page if I remenber to trac the status
18:10:42 <nirik> oh, that reminds me. Currently the migration tool uses trac xmlrpc... could it be made to use sqlite db directly instead?
18:10:50 <nirik> yes, I did make a wiki page, but it needs lots of updating. ;)
18:11:12 <sayan> nirik : btw, don't we need to migrate this: https://fedorahosted.org/fedora-apac/ ?
18:11:16 <nirik> https://fedoraproject.org/wiki/Infrastructure/Fedorahostedmigrations
18:12:08 <linuxmodder> .hello linuxmodder
18:12:09 <zodbot> linuxmodder: linuxmodder 'Corey W Sheldon' <sheldon.corey@openmailbox.org>
18:12:11 <cverna> this is a big table :)
18:12:16 <nirik> sayan: well, owners of projects are supposed to migrate. I mean I would be happy to if they asked us too...
18:12:30 <nirik> but we can't know everything
18:12:48 <sayan> nirik: yeah there was no communications. I would start one then
18:13:07 <nirik> sayan: that would be great. Or any other projects you see in the same situation.
18:13:50 <nirik> #info everyone to check projects still on hosted and urge owners to migrate.
18:14:01 <nirik> Cool. Anything else on status or announcements?
18:14:01 <pingou> do we have a way to know who are the owners?
18:14:26 * pingou was kind of looking for a list of his projects to check all were migrated
18:14:27 <nirik> we can look up TRAC_ADMIN
18:14:28 <linuxmodder> nirik,  working on free-medai should be done by next week
18:14:42 <nirik> linuxmodder: great!
18:14:57 <linuxmodder> we are mostly using it as  membership refresh too
18:15:08 <nirik> linuxmodder: I guess it will be setup the same way it is now? ie the form opens a private pagure ticket?
18:15:48 <linuxmodder> that is the hope yes not totally up to speed on that aspect been more housekeeping and new repos side myself
18:16:06 <nirik> no worries. Hopefully it will all work. 😃
18:16:29 <nirik> ha. The next topic was hosted migrations... which I think we already covered...
18:16:35 <nirik> except...
18:16:35 <linuxmodder> we are also trying to get free-media more inline with ambassadors too
18:17:02 <nirik> cverna: how hard would it be to change the pgimporter to import from a trac sqlite db instead of a trac xmlrpc network connection?
18:17:14 <linuxmodder> nirik, might need a few moments post mtg on some perm questions tho for respins.fic.o
18:17:34 <nirik> sure
18:17:51 <cverna> nirik: not sure, I have noidea how the  trac db is setup
18:18:43 <nirik> ok. The reason I ask is that after we sunset fedorahosted... people will come to us and want to migrate, but we will not have a trac instance up for them, just the data...
18:19:02 <nirik> if they could import from the db that would be nice, instead of having to try and stand up a trac instance to read it.
18:20:05 <cverna> yeah sounds like a better plan
18:20:15 * smooge looks forward to the "Hey no one ever told us..." emails
18:20:15 <nirik> but anyhow, just wanted to get that out there.
18:20:19 <puiterwijk> Well, worst case the pgimport stuff could spin up a new container running trac that loads our database
18:20:25 <nirik> smooge: yeah, there will be tons I am 100% sure.
18:20:38 <nirik> people ignore notices and deadlines.
18:20:48 <puiterwijk> nirik: would it be an idea to start adding a huge banner to all fhosted pages?
18:21:08 <smooge> puiterwijk, probably a good idea
18:21:16 <nirik> puiterwijk: well, that would get users attention, not sure it would get owners attention... but sure.
18:21:19 <linuxmodder> smooge,  there was talk of yet a another sunset article on mag  befor ethe final die off
18:21:41 <puiterwijk> nirik: I'd hope that users would then notify or ask owners :)
18:21:44 <pingou> +1 to both ideas
18:21:52 <pingou> the banner and the fedora magazine article
18:21:55 <smooge> 'YOU HAVE COME TO THE END OF THE UNIVERSE. PLEASE CONTACT THE OWNER ON WHERE THEY ARE MOVING TO'
18:22:03 <nirik> I've sent multiple announce emails and also I have emailed directly all people with TRAC_ADMIN on any trac's.
18:22:09 <nirik> but you can't get everyone. ;)
18:22:19 <puiterwijk> nirik: I don't think I've seen any emails :D
18:22:36 * nirik mail💣s puiterwijk
18:22:53 <linuxmodder> I'll ping the mrkting folks again on that article this or next week with more visibilty
18:23:00 <nirik> linuxmodder: thanks.
18:23:21 <nirik> puiterwijk: you got adding a global banner on your list? or want me to do it? or ?
18:23:26 <puiterwijk> nirik: I got it
18:23:35 <nirik> oh, one other thing we could do...
18:23:35 <puiterwijk> As long as it doesn't have to be pretty :)
18:23:46 <nirik> but not sure how much pain it would be...
18:24:00 <nirik> modify the ssh wrapper to print a banner.
18:24:05 <puiterwijk> So, I'd also suggest that we can keep hosted up for two weeks longer, but in read-only mode..
18:24:22 <puiterwijk> nirik: ah, right. I think that'd be doable. I can look at that
18:24:59 <nirik> puiterwijk: my plan was at sunset day: make everything read-only. Redirect everything to a big banner. We can open particular things to migrate, but otherwise they just go to the banner.
18:25:08 <linuxmodder> nirik,  so the banner on all instances or  just those not migrated
18:25:25 <puiterwijk> nirik: right. That sounds good
18:25:28 <puiterwijk> linuxmodder: I'd say all
18:25:33 <nirik> well, all since we don't know for sure whats migrated.
18:26:16 <linuxmodder> ah and tehn what have the owners do soem backend disable of the banner once migration is confirmed?
18:26:38 <puiterwijk> No, I'd say we keep the banner on for all instances
18:26:40 <nirik> well, I'd say just not bother since everything will go away at the end of the month anyhow. ;)
18:27:03 <nirik> ok, any other hosted migration stuff?
18:27:29 <nirik> #topic Moving SOPs to the proposed infra-docs sphinx project (https://docs.pagure.org/infra-docs/)
18:27:38 <nirik> jcline: any further on this? or was this left from last week?
18:27:53 <jcline> Left from last week, sorry
18:28:00 <nirik> no worries. ;)
18:28:16 <jcline> I've been writing documentation for pagure and I'm about ready to pick a date, though
18:28:17 <nirik> #topic idea to make a packages git repo with all pkgs as submodules - kevin
18:28:22 <nirik> jcline: great!
18:28:31 <pingou> jcline++ thanks for all that doc
18:28:46 <cverna> jcline++
18:28:46 <zodbot> cverna: Karma for jcline changed to 11 (for the f25 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:28:47 <nirik> so there was a suggestion from a user eariler this week I wanted to bring up and see what everyone thought of...
18:29:07 <pingou> form the title, this feels: odd
18:29:08 <nirik> right now all our packages repos are seperate. So if you want to keep them all up to date, you have to git pull in all of them, etc.
18:29:09 * smooge listens
18:29:20 <pingou> (or download the daily checkout)
18:29:29 <nirik> they suggested we make a big over repo that has all the git pkgs repos as submodules.
18:29:42 <nirik> pingou: it's actually weekly I think
18:30:21 <nirik> so with this overrepo you could just 'git pull' and get them all. However, my understanding of submodules is that we would have to update the main repo for every change in any submodules?
18:30:32 <nirik> or can you just say HEAD on all?
18:30:49 <pingou> git-seed is daily
18:31:24 <nirik> ok. I thought it was weekly...
18:31:40 <puiterwijk> nirik: submodules are always a particular commit. They don't follow HEAD automatically
18:31:43 <nirik> yeah, you are right, it's daily
18:32:05 <nirik> puiterwijk: right, so we would need to update that on every commit to any submodule
18:32:20 <puiterwijk> Also, I'm not entirely sure that there's any use in this, since even if you follow the git master, you still only have the git content and not the actual package bits from lookaside
18:32:25 <pingou> I'm afraid about the load on the server if someone does a git pull
18:32:46 <nirik> yeah, there's a lot of repos.
18:32:47 <athos> for every new package, a submodule would have to be added (or removed on retirement)...
18:32:52 <jcline> It would allow the user to easily pull the latest for each submodule, though. That doesn't seem terribly valuable though, if there are daily checkouts
18:33:01 <puiterwijk> Since I think their use was "I can work on packages offline by just downloading everything before I go offline"
18:33:09 <nirik> pingou: would this help pagure in front of packages any? probibly not
18:33:16 <pingou> nirik: nope
18:33:24 <puiterwijk> nirik: Pagure wouldn't make a difference here
18:33:43 <stickster> ouch, someone wants some pain (d/l'ing all package repos?!?)
18:33:51 <pingou> puiterwijk: want to download 17K+ git repo hjust to work on the airplane?
18:33:53 <pingou> Oo
18:33:59 <stickster> pingou: +1
18:34:06 <puiterwijk> pingou: that's what they said...
18:34:08 <stickster> is this a common need?
18:34:21 <nirik> kloczek: http://paste.fedoraproject.org/551887/48666524/ is the discussion before you joined.
18:34:24 <puiterwijk> stickster: I'd say it's a very rare need, and I don't think that it's of any use
18:34:32 <nirik> pingou: 23k more like.
18:34:44 <vivek_> :0
18:34:44 <puiterwijk> Since, as said, you only get the spec files, without the actual content bits etc
18:34:47 <pingou> for pkg in pkgdb-cli list --user=<user> --nameonly; do fedpkg clone $pkg; done
18:34:52 <stickster> it doesn't sound like something we'd want to rearrange all of dist-git to support, absent some real gain
18:35:22 <stickster> pingou: right on, I was thinking pkgdb would get the needful here
18:35:35 <nirik> pingou: well, thats going to be pretty super slow.
18:35:48 <puiterwijk> nirik: git submodules would also be pretty super slow
18:35:53 <nirik> but the checkout seed is the win there
18:36:13 <linuxmodder> kloczek,  feel free to chime in this is your idea after all
18:36:16 <pingou> yeah, I'm not sure the submodules would increase the speed
18:36:30 <pingou> potentially just reduce the number of commands ran
18:36:41 <nirik> dunno. It should actually be possible to create this outside infrastructure...
18:36:45 <kloczek> nirik: yes
18:36:53 <linuxmodder> any idea on the actual increase of load tho pingou  on the server
18:36:56 <nirik> create the repo and modules and have a fedmsg script to update
18:37:45 <pingou> linuxmodder: well, downloading the tarball is one large file, doing git pull on 23K git repo, is quite some more files
18:38:05 <pingou> linuxmodder: so no idea how much more load this would cause, but my gut feeling is saying: more :)
18:38:14 <puiterwijk> I'm going to say lots
18:38:23 <stickster> lots more :-D
18:38:29 <linuxmodder> fair enough
18:38:34 <puiterwijk> Especially if clients use the "smart protocol", since the server will do live compression and packing
18:39:04 <nirik> yeah. It's an interesting idea, but I think the checkout seeds meet this need pretty well already for us.
18:39:14 <puiterwijk> dumb HTTP protocol would just mean tons upon tons of HTTP requests, but the smart protocols would also incur lots of CPU time on the server for the pulls
18:39:30 <puiterwijk> (and we have the smart HTTP protocol enabled)
18:39:33 <nirik> "smart"
18:40:04 <puiterwijk> nirik: well, if you want to get a single repo, it's quite smart. But it does involve lots of server CPU overhead :(. And for 23k repos for a single user...
18:40:20 <nirik> right.
18:40:22 <linuxmodder> so it compresses and packs server side tehn runs the sync ?
18:40:34 <pingou> well, potentially, it's more than one person who would be interested
18:40:48 <pingou> I mean, we've been asked for git-see
18:40:50 <pingou> seed*
18:40:50 <puiterwijk> pingou: right. But it will do a recompress for every person downloading
18:40:56 <pingou> and those people might also be interested in this
18:41:07 <puiterwijk> It does the compressing live
18:41:24 <nirik> anyhow, shall we move on to the next topic?
18:41:25 <linuxmodder> I could see it if it did some sort of parse of which you had and only  did those that way
18:41:30 <puiterwijk> You can see this when you do a git pull: "Remote: Compressing objects xx%"
18:41:32 <pingou> puiterwijk: I'm not saying it'd improve the situation, merely saying that there might be more than one person interested
18:41:52 <puiterwijk> pingou: sure. Which makes it even less wanted in my opinion
18:41:57 <pingou> fair ^^
18:42:23 <kloczek> Guys I have some idea of simplification almost all spec files with libraries
18:42:25 <kloczek> Currently all those packages contains something like:
18:42:29 <kloczek> %post   -p /sbin/ldconfig
18:42:31 <kloczek> %postun -p /sbin/ldconfig
18:42:35 <kloczek> lines like this can be dropped in ALL packages and can be replaced by add in glibc (which contain /sbin/ldconfig):
18:42:39 <kloczek> %transfiletriggerin -- %{_libdir}/lib*.so* -p /sbin/ldconfig
18:42:41 <kloczek> %transfiletriggerin -- %{_lib}/lib*.so* -p /sbin/ldconfig
18:42:49 <nirik> kloczek: yep. But this isn't the place for that. ;)
18:42:50 <kloczek> this very simillar to solaris actions idea
18:42:54 <nirik> kloczek: bring it up on the devel list
18:43:19 <nirik> (and I think some folks were already doing that, but I could be misremembering, but the devel list should know)
18:43:31 <nirik> #topic dist-git upstream progress status - clime
18:43:36 <nirik> clime: take it away
18:43:38 <puiterwijk> "the devel list should know". Love that!
18:43:51 <nirik> am I wrong?
18:43:52 <clime> I made a progress on dist-git upstream.
18:44:07 <puiterwijk> nirik: you're not. Just a great phrasing :)
18:44:07 <clime> Basically there is already a dist-git package in Fedora but is not used (much).
18:44:11 <kloczek> problem is that after introducing such policy it wold be good if smeone would do one massive change introducing something like this ina lla packages
18:44:37 <clime> What I did is that I brought up to date with current state of dist-git in Ansible
18:44:41 <kloczek> if it will be done separatelly by each packages maintainers it will be never introduced consictently
18:45:08 <clime> and then also put gitolite and pkgdb integration away from the package
18:45:17 <clime> so it is trimmed down a lot
18:45:18 <kloczek> the same can be done with for example info page
18:45:23 <kloczek> pages
18:45:42 <clime> which is good becase it can be integrated into COPR and then perehaps onto pkgs staging
18:45:54 <nirik> kloczek: we are the infrastructure group. We run the servers. We don't dictacte the content... thats up to packagers and fesco (who you can find on the devel list)
18:46:04 <clime> I would like to continue on that.
18:46:20 <kloczek> instead adding/removing to info.dir each info document in %post/%postun this file can be automatically regenerated
18:46:25 <nirik> clime: great. Perhaps coordinate with pingou to make sure it works with the pagure frontend?
18:46:57 <clime> nirik: yes, it should. It is very compatible with dist-git on pkgs
18:47:18 <nirik> great. Would be good to get everyone using an upstream there
18:47:19 <pingou> hopefully by next week we'll be able to test pagure on stg dist-git
18:47:22 <clime> I will try that out and talk to pingou if anything will pop up
18:47:27 <pingou> and thus provide a way for clime to double-check that :)
18:47:44 <nirik> sounds good.
18:47:53 <pingou> clime: could the pkgdb and gitolite info be kept in a sub-package or so?
18:48:18 <clime> pingou: well, for the time being I would just deploy it by Ansible
18:48:19 <kloczek> few days ago I told as well on #fedora-admin about organizing one git repo linking all packages repositories
18:48:30 <pingou> clime: fair
18:48:42 <clime> and maybe integrate it slowly over time
18:49:03 <pingou> kloczek: that was the subject we were discussing when you joined :)
18:49:10 <clime> but I think it is good to make the package minimal
18:49:20 <clime> so that it can be used by more people.
18:49:31 <kloczek> pingou: yep :)
18:50:18 <nirik> cool. Anything more on this for now then?
18:50:31 <clime> That was all
18:50:34 <clime> :)
18:50:43 <nirik> thanks for the update clime
18:51:14 <nirik> clime: oh, side note: The copr playbooks seem to have some idempotence issues now... was going to run them by you sometime, or look and fix them myself (but I keep not having time)
18:51:33 <kloczek> example of such linking is zabbix community repos https://github.com/monitoringartist/zabbix-community-repos
18:51:38 <clime> nirik: I'll look at it.
18:51:40 <nirik> #topic Apprentice Open office hours
18:51:54 <nirik> any apprentices with questions or comments or needing things to work on?
18:52:08 <athos> o/
18:52:17 <linuxmodder> athos,  hello
18:52:39 <athos> I am about to propose a project to GSoC and I'd like to check on it's feasibility with you guys :)
18:52:45 <nirik> ok.
18:53:05 <kloczek> because fedora contains +23k packages probably it would be good to organize this like rpm directory tree with first level with only first character name of the pacage
18:53:37 <linuxmodder> athos,  shoot
18:53:38 <athos> basically, I need a lot of static analysis data. So I want to run multiple static analyzers on a bunch of FLOSS projects, continuously. Debian started a similar project, called debile
18:54:06 <linuxmodder> the end game being ? metrics
18:54:13 <kloczek> debile in Polish means idiots (plural form :))
18:54:24 <pingou> same in french (singular form though)
18:54:31 <linuxmodder> kloczek,  please continue on the devel mailing list
18:54:31 <athos> the Idea would be: run various static analyzers in our c/c++packages and have packagers check warnings introduced in the latest package versions (bugs?)
18:54:52 <nirik> athos: this sounds to me like something that could be a taskotron job/check
18:54:58 <athos> linuxmodder: my final goal is to train a ranking algorithm to decrease the importance of false positives
18:55:25 <linuxmodder> then I'm with nirik on the taskatron bit
18:55:29 <kloczek> linuxmodder: ok thx
18:55:36 <linuxmodder> and to me seems viable for GSoC
18:55:48 <pingou> athos: which tool do you have in mind?
18:56:01 <nirik> it could be... but I would talk to QA folks and see if any would be willing to mentor... they may not have time, dunno.
18:56:05 <athos> question: would that be a good project for GSoC? even if not, would it be a nice project to include in the infra?
18:56:31 <athos> pingou: frama-C, cppcheck, flawfinder (there are many)
18:56:55 <pingou> athos: it seems to me like an upstream project more than a Fedora one
18:56:56 <linuxmodder> please consider adding to the idea page for this year: https://fedoraproject.org/wiki/Summer_coding_ideas_for_2017
18:57:13 <pingou> as in, upstream c/c++ dev or upstream of these tools might be interested in the results
18:57:26 <pingou> and using Fedora's sources for this is surely something that is doable
18:57:29 * nirik still thinks it would be a nice taskotron check. ;) well at least that part of it to gather data for whatever
18:57:49 <pingou> nirik: which would tell packagers about issues in the source code?
18:58:01 <nirik> yeah.
18:58:05 <linuxmodder> could datagreper be pulled in for parsing even?
18:58:12 <pingou> unless the packager is upstream, I think most people would just ignore that :s
18:58:21 <nirik> could be yeah...
18:58:32 <pingou> linuxmodder: https://infrastructure.fedoraproject.org/infra/db-dumps/ ?
18:58:58 <linuxmodder> athos,  I'd say draft it mroe concretely and add as a possible on the ideas link I just gave
18:58:59 <athos> my final idea is to reduce the list of warnings (only warnings introduced in specific versions, ranked by probability of being true positives)
18:59:08 <athos> ok :)
18:59:16 <pingou> I'd talk with QA folks
18:59:28 * nirik agrees with pingou that most of the fixes would be done by upstream...
18:59:30 <athos> I will :)
18:59:42 <pingou> but I kinda feels this would be better placed under the umbrella of one of the upstream projects
18:59:45 <linuxmodder> and as someone mentioned ping the qa team ( I will be in GSoC this year but not able to do much on QA side) but maybe someone else in the sig can
19:00:20 <linuxmodder> pingou,  maybe be the pilot for it and have it merged upstream
19:00:42 <pingou> linuxmodder: would still be better to have this hosted by upstream, I don't think that's Fedora's task
19:00:57 <nirik> ok, we are now over time...
19:01:00 <nirik> #topic Open Floor
19:01:02 <athos> by upstream you mean, me or the static analyzers?
19:01:09 <nirik> any quick open floor items?
19:01:14 <linuxmodder> athos,  the projects use it
19:01:23 <nirik> athos: the analyzers... since you are trying to improve them.
19:01:33 <pingou> athos: yes
19:01:33 <linuxmodder> I'll ping you offline nirik  with mine on account of time
19:02:10 <nirik> ok, I'm always in #fedora-admin for questions. ;)
19:02:24 <nirik> ok, will end the meeting in a minute or less unless something more comes up
19:03:02 <nb> bexelbie, ping
19:03:03 <zodbot> nb: Ping with data, please: https://fedoraproject.org/wiki/No_naked_pings
19:03:07 <nb> pm
19:03:07 <smooge> thank you nirik
19:03:17 <nirik> thanks for coming everyone. :)
19:03:19 <cverna> thanks nirik
19:03:19 <nirik> #endmeeting