From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Q2BeI-0007Rb-HI for garchives@archives.gentoo.org; Wed, 23 Mar 2011 00:10:06 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B5B8D1C016; Wed, 23 Mar 2011 00:09:46 +0000 (UTC) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by pigeon.gentoo.org (Postfix) with SMTP id 3FBB51C016 for ; Wed, 23 Mar 2011 00:09:46 +0000 (UTC) Received: (qmail invoked by alias); 23 Mar 2011 00:09:45 -0000 Received: from p549BD88B.dip.t-dialin.net (EHLO [10.0.0.7]) [84.155.216.139] by mail.gmx.net (mp054) with SMTP; 23 Mar 2011 01:09:45 +0100 X-Authenticated: #1855979 X-Provags-ID: V01U2FsdGVkX198mWkKfPl8NdOGf8IEwYAaFsbvEDsO6h46Yu/kMj /TSp6rdr7PYGSB Message-ID: <4D893A42.7020308@gmx.net> Date: Wed, 23 Mar 2011 01:09:38 +0100 From: Michael Seifert User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110321 Lightning/1.0b3pre Thunderbird/3.1.9 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-soc@lists.gentoo.org Reply-to: gentoo-soc@lists.gentoo.org MIME-Version: 1.0 To: gentoo-soc@lists.gentoo.org Subject: Re: [gentoo-soc] GSoC - Package statistics References: <4D87E1AC.1030201@gmx.net> <1300755118.31104.110.camel@big_daddy.dol-sen.ca> <820e13d818f9b5f7452706ff566c7563@basementcode.com> <1300769995.31104.137.camel@big_daddy.dol-sen.ca> In-Reply-To: <1300769995.31104.137.camel@big_daddy.dol-sen.ca> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Archives-Salt: X-Archives-Hash: 0bfef80f1877abb0443c65001bac1ff4 -----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 >> 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-----