| 1 |
Hola all- |
| 2 |
|
| 3 |
I've already written up the synopsis on the wiki under 'gentoo-x86 QA |
| 4 |
website' ( |
| 5 |
http://en.gentoo-wiki.com/wiki/Google_Summer_of_Code_2010_ideas ) so |
| 6 |
please free to expand what's already written there. |
| 7 |
|
| 8 |
Roughly, there should be a website built to display current QA issues |
| 9 |
w/ the mainline gentoo tree; useful views include- |
| 10 |
|
| 11 |
1) herd views- what QA issues affect pkgs owned by a certain herd |
| 12 |
2) keyword/arch views- what QA issues affect my arch? |
| 13 |
3) pkg level view- if I'm looking to keyword this, or stable it, what |
| 14 |
issues are known for the target pkg? |
| 15 |
4) breakdown per QA type. For example, what pkgs in the tree |
| 16 |
currently have broken 'visibility'? Visibility in this case means |
| 17 |
they depend on something that isn't usable- for example, of pkg A is |
| 18 |
x86 keyworded, depends on pkg B, but no version of pkg B is usable |
| 19 |
(whether via lacking x86 keyword, or package masked). |
| 20 |
5) alternate export methods for these views- while html is useful, |
| 21 |
exporting say rss or xml so that folks can pull the data down into |
| 22 |
their own setup would be *very* useful. Via such an export, someone |
| 23 |
down the line could attempt to do some form of view intermixing |
| 24 |
bugzilla data for example. |
| 25 |
6) whatever devs would like that is doable, and useful. |
| 26 |
7) not required, but would likely be very useful- repository level |
| 27 |
view. At some point it's likely that any such QA site will include |
| 28 |
data from multiple repositories- gentoo-x86 and the gnome overlay for |
| 29 |
example. Any views on the site should be designed w/ that in mind, |
| 30 |
even if the final product doesn't _yet_ support multiple repositories. |
| 31 |
|
| 32 |
|
| 33 |
As for how one would pull this project off, there are essentially two |
| 34 |
components to this- |
| 35 |
|
| 36 |
*) data importation from existing QA tools |
| 37 |
|
| 38 |
*) web frontend accessing said data- I'd *strongly* suggest using a |
| 39 |
web framework of some sort for this to make maintaince and extension |
| 40 |
down the line easy, and to open up the potential of a generic search |
| 41 |
facility. |
| 42 |
|
| 43 |
For any candidate looking to try this, I *strongly* suggest that for |
| 44 |
data importation they first target using pkgcore-checks; reasons |
| 45 |
follow- |
| 46 |
|
| 47 |
*) fast. realistically it would be nice to have a max lag of 30 |
| 48 |
minutes for gentoo-x86 (near real time), this requires the QA tool to |
| 49 |
be as fast as possible- currently pcheck is around 6 minutes for a |
| 50 |
full hot-cache scan, so this leaves a large amount of time w/in the 30 |
| 51 |
minute target for whatever data importation is needed, view |
| 52 |
rendering, etc. pcheck's speed should allow this, which will make the |
| 53 |
resultant site far more useful to devs- they can look at the site and |
| 54 |
know that right now, visibility is broken for the following pkgs (thus |
| 55 |
they need to go fix it). |
| 56 |
|
| 57 |
*) it's already designed to export it's data in a programatic way- |
| 58 |
specifically it has the option of outputing it's QA results as a |
| 59 |
pickle stream. This proposal was already attempted once (failed due |
| 60 |
to slowness issues w/ django and real life intruding), that said the |
| 61 |
data export from pcheck is ready *now* for data importation. |
| 62 |
Regardless of who mentor's such a proposal, I'll commit to ensuring |
| 63 |
that the data exportation of pcheck is working and ensure that the |
| 64 |
candidate can use the data. |
| 65 |
|
| 66 |
|
| 67 |
Note that while I'm strongly suggesting people initially target pcheck |
| 68 |
data, that's purely so that they can focus on getting a web frontend |
| 69 |
up- the underlying schema *needs* to be written in a fashion that |
| 70 |
other QA tools can be plugged in. Pcheck data is suggested purely as |
| 71 |
the first data import target- any proposal put forth will need to have |
| 72 |
a way for other tool's data to be imported. |
| 73 |
|
| 74 |
This doesn't necessarily mean the candidate has to write the data |
| 75 |
importation for the other tools (repoman would be a good target |
| 76 |
though), it just means that they have to design the innards to allow |
| 77 |
for it. |
| 78 |
|
| 79 |
Hopefully that makes sense- if not feel free to ask for clarification. |
| 80 |
|
| 81 |
Finally, as for web frameworks, it's really the candidates choice |
| 82 |
although I'd personally suggest something python based so that the |
| 83 |
data importers (which is python for pkgcore, likely python for |
| 84 |
portage, ruby/python for paludis when they regrow QA checks) are in |
| 85 |
the same language, able to access the same models. That said it's the |
| 86 |
candidates choice of course- merely a suggestion. |
| 87 |
|
| 88 |
~harring |
Archives