1 |
On Mon, 2011-03-21 at 22:22 -0500, chris@××××××××××××.com wrote: |
2 |
> On Mon, 21 Mar 2011 17:51:58 -0700, Brian Dolbec |
3 |
> <brian.dolbec@×××××.com> wrote: |
4 |
> > On Tue, 2011-03-22 at 00:39 +0100, Michael Seifert wrote: |
5 |
> >> -----BEGIN PGP SIGNED MESSAGE----- |
6 |
> >> Hash: SHA1 |
7 |
> >> |
8 |
> >> Hello Gentoo team, |
9 |
> >> |
10 |
> >> I am interested in taking part in this year's Google Summer of Code |
11 |
> >> and |
12 |
> >> would like to discuss some general things. More specific, I am |
13 |
> >> talking |
14 |
> >> about Christopher Harvey's idea to design an application that raises |
15 |
> >> statistics on the installed packages on a system (see [1]). |
16 |
> >> |
17 |
> >> Let me explain my issue: |
18 |
> >> In the first place, I am a Java developer and I consider my Java |
19 |
> >> skills |
20 |
> >> to be quite well. The point is that java is not part of a minimal |
21 |
> >> gentoo |
22 |
> >> system, whereas Python is. I would not have problems with Python, |
23 |
> >> but I |
24 |
> >> would have to learn the API of a GUI toolkit (preferably PyQt). |
25 |
> >> What is your opinion: Would you be okay with a Java application or |
26 |
> >> would |
27 |
> >> you rather like to have a Python based one or even some other |
28 |
> >> language? |
29 |
> >> And finally, how much time do you think will it cost to work through |
30 |
> >> the |
31 |
> >> Qt API? |
32 |
> >> |
33 |
> >> |
34 |
> > |
35 |
> > Well, a good deal of the info gathering methods are already coded in |
36 |
> > python (by me) and installed on many users systems already, soon to |
37 |
> > be |
38 |
> > even more as gentoolkit-0.3.0 final is about to be released. |
39 |
> > |
40 |
> > Have a look at the analyse module. It is designed for accessing the |
41 |
> > installed package database and reporting/repairing things about it. |
42 |
> > There is room for many more types of reports depending what is |
43 |
> > needed. |
44 |
> > Adding an anonymous data upload should not be difficult. So far I |
45 |
> > have |
46 |
> > only been adding report types for problems users have run into. It |
47 |
> > has |
48 |
> > USE flags and keywords reports so far. It has an api to use so as to |
49 |
> > not need terminal output parsing to get the relevant data out of it. |
50 |
> > Also so does most of equery and eclean have usable api's now (if |
51 |
> > there |
52 |
> > is anything needed from there (the reason I got involved in |
53 |
> > gentoolkit |
54 |
> > coding). |
55 |
> Glad to hear gentoolkit has an API. |
56 |
> > |
57 |
> > I don't think a gui would be needed, but rather webapp interfaces to |
58 |
> > the |
59 |
> > data gathered. Most of the devs are cli die hards, so a simple |
60 |
> > command |
61 |
> > line interface to query the central database should be primary. I |
62 |
> > believe it would be more widely used for the ebuilds they maintain. A |
63 |
> > browser could be used to connect to it and get graphs, etc. for more |
64 |
> > elaborate info displays. |
65 |
> I had envisioned the webapp as being the main frontend, but since users |
66 |
> would probably feel more comfortable with entering useful data via a |
67 |
> simple and minimal gui on the client side. |
68 |
|
69 |
well, the only time a gui might be useful is selecting the responses to |
70 |
pkg queries a dev my trigger to be asked. All the info gathering could |
71 |
be done in a cronjob, maybe once a week, month,... and possibly sent |
72 |
automatically if that option is selected. no user intervention or data |
73 |
entry is needed after initial setup. |
74 |
|
75 |
> > |
76 |
> > I would think the main portion of this project would be the database |
77 |
> > and |
78 |
> > webapp query tools. Potential controversy aside, I would also think |
79 |
> > you |
80 |
> > should add a mechanism for a dev to trigger a simple query for people |
81 |
> > having a cat/pkg-ver installed to optionally fill in a few questions |
82 |
> > regarding an pkg's stability,... all anonymously. Those queries |
83 |
> > could |
84 |
> > be generic in nature and come with the data gathering tool, that way |
85 |
> > only a simple small string need be downloaded at the time of data |
86 |
> > upload |
87 |
> > (for ex: pkgname, query #, possibly a bug #) no executable code. |
88 |
> Agreed, maybe to avoid making the program annoying it could only run |
89 |
> when the user asks it to. |
90 |
|
91 |
Yes the triggered queries would only put a notice to an email, or |
92 |
systray icon,... Answering them and sending would be when the user |
93 |
selected only. |
94 |
|
95 |
> > |
96 |
> > So I would concentrate your research and proposal efforts on the |
97 |
> > database and webapps. |
98 |
> |
99 |
> I'm not a developer, so I don't think I can mentor this project even |
100 |
> though I had the original idea. As of now, as far as I know this project |
101 |
> has no mentor. Brian, as the author of gentoolkit and having such |
102 |
> similar ideas for this project as me I'd be happy to see you mentor it |
103 |
> if you want to. |
104 |
> |
105 |
> -Chris |
106 |
|
107 |
Well, I would not be a good mentor for the webapp portion, since I |
108 |
have not done any webapp programming outside of trying to tweak a couple |
109 |
existing programs. However for the user side of data collection, yes I |
110 |
would take it on if the powers that be so choose. I would still help if |
111 |
asked even if not chosen as co-mentor. |
112 |
|
113 |
Also being an official gentoo developer is not a pre-requisite to be a |
114 |
mentor. If you feel you have the qualifications for this task. Get in |
115 |
touch with dberkholz and antarus, the sooner the better for them to |
116 |
evaluate you. |
117 |
|
118 |
|
119 |
-- |
120 |
Brian Dolbec <brian.dolbec@×××××.com> |