Provide some metrics in Debile
Name: Clément Schreiner
Contact/Email: mailto:clement@mux.me - irc://irc.oftc.net/clemux
Background: I am a 22-year-old student in computer science at University of Strasbourg (France).
I am familiar with free software, as an user since 2004, and a developer since 2010: I have made occasional contributions to the Weboob framework, which allows easy interactions between console or graphical applications and various websites.
I have participated to the 2012 Summer of Code, working on debexpo. You can read my final report to get an idea about what I did. For a good part of the summer, I have struggled with designing a good plugin system for debexpo's various sources of data.
Thus, I have experience with team work, VCS, bugtrackers and mailing lists. My last summer of code taught me a lot about the Debian process and how to interacting with packages in python. Because I revamped the plugin architecture, I have rewritten all QA tests plugins and learned how to retrieve data from the BTS, debtags, lintian, etc. That project has improved my python skills, and gave me some experience with sqlalchemy.
Project title Provide some metrics in Debile
Project details: Debile's web UI is currently very spartan and most of the data stored by debile-master is inaccessible to users. For the small subset of data that can be viewed, the interface is neither precise nor pleasant to the eye. This project aims both to make more stuff available outside debile-master and to make their representation ergonomic and visually pleasing , so that:
- uploaders can easily see where their packages are in the build process
- upstream developers can easily see what tools have run on their software, what has been checked and what they need to fix
- everyone gets beautiful graphics of the evolution of issues left in packages, as a motivation aid for fixing them
- interested third-parties are able to get an idea of the type of analyses are done, what are the more common problems, and various other statistics
List of metrics
- evolution over the time of the number of uploads, sources, binaries, builds completed/failed/waiting, total build time (per day, week, …). That data is already in debile's database.
- → one D3 graph, filtered by (AND/OR queries):
- uploader, maintainer, build status (finished, queued, waiting for dep, failed, …)
- for builds: by job type, error type, builder
- → one D3 graph, filtered by (AND/OR queries):
- evolution of builds results for a single upload, with package version as the x-axis
- → one D3 graph, filtered by:
- build type (build, static analyzer, dynamic analyzer)
- error type (pedantic/warning/error… depends on the analyzer)
- → one D3 graph, filtered by:
- metrics on source package. (this kind of data is already on sources.debian.net)
- programming languages used (with lines of code)
- source size
- → new analyzer for debile slaves
- metrics on binary packages, filtered by architecture
- binary size
- build time
- …
- → new analyzer for debile slaves
- evolution over the time of the number of uploads, sources, binaries, builds completed/failed/waiting, total build time (per day, week, …). That data is already in debile's database.
Synopsis
Benefits to Debian
Deliverables:
- various statistics either global or specific to packages, builders, users or analyzers
- graphical representation for those statistics
- plots depicting the evolution of some statistics over time
- nice and dynamic interface for accessing all those metrics in a practical way
- integration of firewoes into debile-web
- new analyzers for debile
- various improvements to debile-web whenever they are needed
Project schedule:
I will add new metrics in a cyclical fashion, so that fully usable code gets merged in the master branch regularly. My biggest mistaked during my debexpo GSoC (2012) was trying to do each task perfectly before switching to the next one, and I want to avoid that this time. I'll use the community bonding period and the last weeks of August as safety buffers in case I get delayed on some subproject because of unexpected difficulties.
- make graphics for the data already available
- display existing analyzers' results, using firewoes
- improve firewoes if necessary
- add new analyzers
- make runners/analyzers for an analyzer
- check that firewoes is able to display the new results correctly, otherwise improve it
- if the new results make possible new metrics, add those
- → 1.
Detailed schedule:
community bonding period
Week 1
Week 2
- …
Exams and other commitments: last exams at the end of May; I can compensate by working during the community bonding period
Other summer plans: None
Why Debian?: I have used Debian since 2004 and I am interested in its internal processes and policies
- I am not applying to other Summer of Code projects