Gentoo Archives: gentoo-soc

From: Brian Harring <ferringb@×××××.com>
To: gentoo-soc@l.g.o
Subject: [gentoo-soc] QA website
Date: Mon, 22 Mar 2010 01:50:47
Message-Id: 20100322014846.GA9458@hrair
1 Hola all-
3 I've already written up the synopsis on the wiki under 'gentoo-x86 QA
4 website' (
5 ) so
6 please free to expand what's already written there.
8 Roughly, there should be a website built to display current QA issues
9 w/ the mainline gentoo tree; useful views include-
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.
33 As for how one would pull this project off, there are essentially two
34 components to this-
36 *) data importation from existing QA tools
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.
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-
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).
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.
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.
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.
79 Hopefully that makes sense- if not feel free to ask for clarification.
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.
88 ~harring