Re: [gentoo-soc] GSoC - Package statistics

On Mon, 21 Mar 2011 17:51:58 -0700, Brian Dolbec 
 <brian.dolbec@×××××.com> wrote:
> On Tue, 2011-03-22 at 00:39 +0100, Michael Seifert wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hello Gentoo team,
>>
>> I am interested in taking part in this year's Google Summer of Code
>> and
>> would like to discuss some general things. More specific, I am
>> talking
>> about Christopher Harvey's idea to design an application that raises
>> statistics on the installed packages on a system (see [1]).
>>
>> Let me explain my issue:
>> In the first place, I am a Java developer and I consider my Java
>> skills
>> to be quite well. The point is that java is not part of a minimal
>> gentoo
>> system, whereas Python is. I would not have problems with Python,
>> but I
>> would have to learn the API of a GUI toolkit (preferably PyQt).
>> What is your opinion: Would you be okay with a Java application or
>> would
>> you rather like to have a Python based one or even some other
>> language?
>> And finally, how much time do you think will it cost to work through
>> the
>> Qt API?
>>
>>
>
> Well, a good deal of the info gathering methods are already coded in
> python (by me) and installed on many users systems already, soon to
> be
> even more as gentoolkit-0.3.0 final is about to be released.
>
> Have a look at the analyse module.  It is designed for accessing the
> installed package database and reporting/repairing things about it.
> There is room for many more types of reports depending what is
> needed.
> Adding an anonymous data upload should not be difficult.  So far I
> have
> only been adding report types for problems users have run into.  It
> has
> USE flags and keywords reports so far.  It has an api to use so as to
> not need terminal output parsing to get the relevant data out of it.
> Also so does most of equery and eclean have usable api's now (if
> there
> is anything needed from there (the reason I got involved in
> gentoolkit
> coding).
 Glad to hear gentoolkit has an API.
>
> I don't think a gui would be needed, but rather webapp interfaces to
> the
> data gathered.  Most of the devs are cli die hards, so a simple
> command
> line interface to query the central database should be primary. I
> believe it would be more widely used for the ebuilds they maintain. A
> browser could be used to connect to it and get graphs, etc. for more
> elaborate info displays.
 I had envisioned the webapp as being the main frontend, but since users 
 would probably feel more comfortable with entering useful data via a 
 simple and minimal gui on the client side.
>
> I would think the main portion of this project would be the database
> and
> webapp query tools.  Potential controversy aside, I would also think
> you
> should add a mechanism for a dev to trigger a simple query for people
> having a cat/pkg-ver installed to optionally fill in a few questions
> regarding an pkg's stability,... all anonymously.  Those queries
> could
> be generic in nature and come with the data gathering tool, that way
> only a simple small string need be downloaded at the time of data
> upload
> (for ex: pkgname, query #, possibly a bug #) no executable code.
 Agreed, maybe to avoid making the program annoying it could only run 
 when the user asks it to.
>
> So I would concentrate your research and proposal efforts on the
> database and webapps.

 I'm not a developer, so I don't think I can mentor this project even 
 though I had the original idea. As of now, as far as I know this project 
 has no mentor. Brian, as the author of gentoolkit and having such 
 similar ideas for this project as me I'd be happy to see you mentor it 
 if you want to.

 -Chris