I've already written up the synopsis on the wiki under 'gentoo-x86 QA
http://en.gentoo-wiki.com/wiki/Google_Summer_of_Code_2010_ideas ) so
please free to expand what's already written there.
Roughly, there should be a website built to display current QA issues
w/ the mainline gentoo tree; useful views include-
1) herd views- what QA issues affect pkgs owned by a certain herd
2) keyword/arch views- what QA issues affect my arch?
3) pkg level view- if I'm looking to keyword this, or stable it, what
issues are known for the target pkg?
4) breakdown per QA type. For example, what pkgs in the tree
currently have broken 'visibility'? Visibility in this case means
they depend on something that isn't usable- for example, of pkg A is
x86 keyworded, depends on pkg B, but no version of pkg B is usable
(whether via lacking x86 keyword, or package masked).
5) alternate export methods for these views- while html is useful,
exporting say rss or xml so that folks can pull the data down into
their own setup would be *very* useful. Via such an export, someone
down the line could attempt to do some form of view intermixing
bugzilla data for example.
6) whatever devs would like that is doable, and useful.
7) not required, but would likely be very useful- repository level
view. At some point it's likely that any such QA site will include
data from multiple repositories- gentoo-x86 and the gnome overlay for
example. Any views on the site should be designed w/ that in mind,
even if the final product doesn't _yet_ support multiple repositories.
As for how one would pull this project off, there are essentially two
components to this-
*) data importation from existing QA tools
*) web frontend accessing said data- I'd *strongly* suggest using a
web framework of some sort for this to make maintaince and extension
down the line easy, and to open up the potential of a generic search
For any candidate looking to try this, I *strongly* suggest that for
data importation they first target using pkgcore-checks; reasons
*) fast. realistically it would be nice to have a max lag of 30
minutes for gentoo-x86 (near real time), this requires the QA tool to
be as fast as possible- currently pcheck is around 6 minutes for a
full hot-cache scan, so this leaves a large amount of time w/in the 30
minute target for whatever data importation is needed, view
rendering, etc. pcheck's speed should allow this, which will make the
resultant site far more useful to devs- they can look at the site and
know that right now, visibility is broken for the following pkgs (thus
they need to go fix it).
*) it's already designed to export it's data in a programatic way-
specifically it has the option of outputing it's QA results as a
pickle stream. This proposal was already attempted once (failed due
to slowness issues w/ django and real life intruding), that said the
data export from pcheck is ready *now* for data importation.
Regardless of who mentor's such a proposal, I'll commit to ensuring
that the data exportation of pcheck is working and ensure that the
candidate can use the data.
Note that while I'm strongly suggesting people initially target pcheck
data, that's purely so that they can focus on getting a web frontend
up- the underlying schema *needs* to be written in a fashion that
other QA tools can be plugged in. Pcheck data is suggested purely as
the first data import target- any proposal put forth will need to have
a way for other tool's data to be imported.
This doesn't necessarily mean the candidate has to write the data
importation for the other tools (repoman would be a good target
though), it just means that they have to design the innards to allow
Hopefully that makes sense- if not feel free to ask for clarification.
Finally, as for web frameworks, it's really the candidates choice
although I'd personally suggest something python based so that the
data importers (which is python for pkgcore, likely python for
portage, ruby/python for paludis when they regrow QA checks) are in
the same language, able to access the same models. That said it's the
candidates choice of course- merely a suggestion.