[gentoo-soc] QA website

[gentoo-soc] QA website

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 4346 bytes --]

Hola all-

I've already written up the synopsis on the wiki under 'gentoo-x86 QA 
website' ( 
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 
facility.

For any candidate looking to try this, I *strongly* suggest that for 
data importation they first target using pkgcore-checks; reasons 
follow-

*) 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 
for it.

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.

~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]