Re: [gentoo-soc] GSoC - Package statistics

[Michael Seifert <michael.seifert@gmx.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 22.03.2011 05:59, schrieb Brian Dolbec:
> On Mon, 2011-03-21 at 22:22 -0500, chris@basementcode.com wrote:
>> On Mon, 21 Mar 2011 17:51:58 -0700, Brian Dolbec 
>>  <brian.dolbec@gmail.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.
> 
> well, the only time a gui might be useful is selecting the responses to
> pkg queries a dev my trigger to be asked.  All the info gathering could
> be done in a cronjob, maybe once a week, month,... and possibly sent
> automatically if that option is selected.  no user intervention or data
> entry is needed after initial setup.
> 
>>>
>>> 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.
> 
> Yes the triggered queries would only put a notice to an email, or
> systray icon,...  Answering them and sending would be when the user
> selected only.
>  
>>>
>>> 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
> 
>   Well, I would not be a good mentor for the webapp portion, since I
> have not done any webapp programming outside of trying to tweak a couple
> existing programs.  However for the user side of data collection, yes I
> would take it on if the powers that be so choose.  I would still help if
> asked even if not chosen as co-mentor. 
> 
>   Also being an official gentoo developer is not a pre-requisite to be a
> mentor.  If you feel you have the qualifications for this task.  Get in
> touch with dberkholz and antarus, the sooner the better for them to
> evaluate you.
> 
> 

I agree that a web-based querying tool/platform would be important. But,
to be honest, this is not exactly what I was hoping to do, when I read
the project idea. Mainly because it is not what I am looking for and
secondly because I am not very much into web development myself (except
for some small zope projects). Anyway, it is good to discuss things now
better than late.
Sorry, if I caused any inconvenience.
Be sure, however, that I will ask some more questions on another topic,
if you don't mind. :)

For the thouroughness of the discussion and out of personal interest:
The webapp should most likely integrate nicely on the gentoo website.
What CMS does gentoo.org use and what CMS would you suggest to an applicant?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2JOkIACgkQnzX+Jf4GTUxI1ACeJikHVy2hi7JT07xcGym7eq6R
8IEAn1mfG5BxmyAYVQvIycQQTnVXNeUn
=2Ntc
-----END PGP SIGNATURE-----