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 |