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