Re: Self introduction: David Carlos - Gsoc Student
Welcome, David On Mon, May 15, 2017 at 11:05:43PM +0200, Dridi Boukelmoune wrote: > > The main ideia is to monitor repositories, and when a new package or > > a new version of an existent package is released, we download the package > > source code, > > and run several static analyzers on it. Each monitored distribution will be > > a kiskadee > > plugin, that implements an interface that we will define. The result of > > these > > analyses, which is parsed using the Fedora Firehose project, will be > > stored in a relational database (this idea has been discussed a while ago > > in the > > devel mailing lists, by the guys in the Static Analysis SIG [2]). With this > > database several analyses can be made, and by using several static > > analyzers we > > want to find heuristics to identify false positives (this is not part of > > GSoC > > though). > > Having myself recently found a bug in zlib thanks to static analysis I > was a bit surprised that such a critical library wouldn't get more > "static" eyes on it. > > > A similar tool exists in the Debian distribution, but it is way > > dependent on their infrastructure, and one of our objetives is to keep > > kiskadee > > simple, and extensible. > > Naive question, but wouldn't it be interesting to piggyback on > release-monitoring.org and fedmsg for the monitoring part? And start > static analysis when notified of new upstream releases? That is a great idea which we haven't considered yet. We will definitely consider doing so (the idea is to have an extensible tool which we could point to different software repositories). Thank you for the input! I Cc'd the summer-coding mailing list here :) -- Athos Ribeiro http://www.ime.usp.br/~athoscr ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Self introduction: David Carlos - Gsoc Student
> The main ideia is to monitor repositories, and when a new package or > a new version of an existent package is released, we download the package > source code, > and run several static analyzers on it. Each monitored distribution will be a > kiskadee > plugin, that implements an interface that we will define. The result of these > analyses, which is parsed using the Fedora Firehose project, will be > stored in a relational database (this idea has been discussed a while ago in > the > devel mailing lists, by the guys in the Static Analysis SIG [2]). With this > database several analyses can be made, and by using several static analyzers > we > want to find heuristics to identify false positives (this is not part of GSoC > though). Having myself recently found a bug in zlib thanks to static analysis I was a bit surprised that such a critical library wouldn't get more "static" eyes on it. > A similar tool exists in the Debian distribution, but it is way > dependent on their infrastructure, and one of our objetives is to keep > kiskadee > simple, and extensible. Naive question, but wouldn't it be interesting to piggyback on release-monitoring.org and fedmsg for the monitoring part? And start static analysis when notified of new upstream releases? Interesting project all the same! Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Self introduction: David Carlos - Gsoc Student
Hey guys, My name is David Carlos, and I am a GSoC student, working with Fedora. This email is to present myself, and what I pretend to do during the GSoC period. I am a student from University of Brasilia, in Brazil, and in the middle of the year I get my software engineering bachelor degree. I have contributed to some open source projects, and with this experience I realized how a good QA environment can help developing better software. With this in mind Athos and I idealized the kiskadee system [1]. kiskadee will be a tool to help Linux distributions (and other software repositories) to continuously measure the quality of packages source code. The main ideia is to monitor repositories, and when a new package or a new version of an existent package is released, we download the package source code, and run several static analyzers on it. Each monitored distribution will be a kiskadee plugin, that implements an interface that we will define. The result of these analyses, which is parsed using the Fedora Firehose project, will be stored in a relational database (this idea has been discussed a while ago in the devel mailing lists, by the guys in the Static Analysis SIG [2]). With this database several analyses can be made, and by using several static analyzers we want to find heuristics to identify false positives (this is not part of GSoC though). A similar tool exists in the Debian distribution, but it is way dependent on their infrastructure, and one of our objetives is to keep kiskadee simple, and extensible. I am very happy that I was acepted in GSoC to work with Fedora. I have some rpm packing experience, and hope to keep contributing with Fedora after the GSoC period ends. [1] the great kiskadee is a bird that watches its prey (usually bugs) and catch them in flight. [2] https://fedoraproject.org/wiki/StaticAnalysis -- David Carlos http://davidcarlos.github.io/ signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
