Bug#468132: ITP: packagekit -- PackageKit provides a distribution neutral interface to manage software packages. It provides a system wide daemon that performs tasks like refreshing the cash, updating
Package: wnpp Severity: wishlist Owner: Sebastian Heinlein <[EMAIL PROTECTED]> * Package name: packagekit Version : 0.1.8 Upstream Author : Richard Hughsie <[EMAIL PROTECTED]> * URL : http://www.packagekit.org * License : GPL2+ Programming Lang: C, Python Description : PackageKit provides a distribution neutral interface to manage software packages. It provides a system wide daemon that performs tasks like refreshing the cash, updating, installing and removing software independetly from the user interface. By default, PackageKit uses PolicyKit for user authentication. This allows to specify with fine-grained control what your users can and cannot do. (Include the long description here.) -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Google Summer of Code 2008
On Wed, Feb 27, 2008 at 09:42:17AM +0100, Lucas Nussbaum wrote: > I have had a problem with the way GSOC was handled in Debian in the past > years. > > Many of the students that were selected were already well-known Debian > contributors or developers. The first problem with that is that some of As one of the admin last year, and also as a mentor which had has his student a Debian contributor (which indeed led to an unsuccessful project IMO), I fully agree with this "problem" of yours. Also, on a more general basis, I (now) agree that the principle should be "let's use GSoC for attracting new contributors, not to pay who is already a contributor". > (1) Forbid DDs and people in the NM process waiting for FD/DAM to apply > as students. I'm not sure we will be able to reach a consensus on this, but my vote would be for this point. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -<%>- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: Google Summer of Code 2008
> > (1) Forbid DDs and people in the NM process waiting for FD/DAM to > > apply as students. > > I'm not sure we will be able to reach a consensus on this, but my vote > would be for this point. Seconded. :) Greetings Winnie > > Cheers. -- .''`. Patrick Winnertz <[EMAIL PROTECTED]> : :' : GNU/Linux Debian Developer `. `'` http://www.der-winnie.de http://people.skolelinux.org/~winnie `- Debian - when you have better things to do than fixing systems signature.asc Description: This is a digitally signed message part.
Re: Idea of Debian mascot
On Wed, Feb 27, 2008 at 12:23:33AM -0600, Anibal Avelar wrote: > http://fixxxer.cc/images/mascot/Mascot_Harmony_without_Strings_by_ravenmosher.jpg That looks like some sort of big eyeball? Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#468132: ITP: packagekit [...]
On Wed, Feb 27, 2008 at 08:53:04AM +0100, Sebastian Heinlein wrote: > * Package name: packagekit > Description : PackageKit provides a distribution neutral interface to > manage software packages. It provides a system wide daemon that performs > tasks like refreshing the cash, updating, installing and removing software > independetly from the user interface. By default, PackageKit uses PolicyKit > for user authentication. This allows to specify with fine-grained control > what your users can and cannot do. > > (Include the long description here.) Debian packages have both a short description and a long one. I also see you made some spelling errors. I suggest the following short and long description: Description: distribution neutral software package manager PackageKit provides a distribution neutral interface to manage software packages. It provides a daemon that refreshes the package cache, updates, installs and removes packages independent of the user interface. . By default, PackageKit uses PolicyKit to provide fine-grained access control. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Google Summer of Code 2008
On Wed, Feb 27, 2008 at 09:55:23AM +0100, Patrick Winnertz wrote: > > > > (1) Forbid DDs and people in the NM process waiting for FD/DAM to > > > apply as students. > > > > I'm not sure we will be able to reach a consensus on this, but my vote > > would be for this point. I'm not completely persuaded this is correct. Someone should explain why an existing contributor does not concentrate his/her efforts on the choosen project instead of wasting time in other tasks, and why a new contributor should not do that. I think it is a management problem, not a choice of contributors. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Configuration Packaging System
On Sun, 24 Feb 2008 17:15:48 -0800, Russ Allbery <[EMAIL PROTECTED]> wrote: >Timothy G Abbott <[EMAIL PROTECTED]> writes: >> Anders Kaseorg and I created a system of CDBS modules (which we've >> tentatively packaged as the config-package-dev package) for creating >> Debian configuration packages. By configuration packages, we mean >> packages that configure an existing Debian system by applying >> dpkg-divert to configuration files. Our configuration package system >> makes the process of creating configuration packages efficient. > >It's generally accepted wisdom that dpkg-divert doesn't work properly with >configuration files and isn't safe. Which is actually a big pity since I have been looking for a method to roll out _configuration_ to a lot of systems by means of the already in-place, apt-based software distribution system. I have once experimented with using ucf to force in new configuration, but that has shown to have "interesting" quirks. A different method would be to background a job which waits until no apt or dpkg jobs are running and more and does the conffile change then, but that's a very bad hack. We need a documented way to do those things. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Google Summer of Code 2008
Hey, > > > > (1) Forbid DDs and people in the NM process waiting for FD/DAM to > > > > apply as students. > > > > > > I'm not sure we will be able to reach a consensus on this, but my > > > vote would be for this point. > > I'm not completely persuaded this is correct. Someone should explain > why an existing contributor does not concentrate his/her efforts on > the choosen project instead of wasting time in other tasks, and > why a new contributor should not do that. I think it is a management > problem, not a choice of contributors. Mh.. yes this is correct. But this is not the reason why I seconded this.. I seconded this as the Google Summer of Code is meant for people to get in touch with open source projects and to get new contributors. And someone who waits for FD/DAM or is already a DD is not really new to debian. Just my 2c. Greetings Winnie -- .''`. Patrick Winnertz <[EMAIL PROTECTED]> : :' : GNU/Linux Debian Developer `. `'` http://www.der-winnie.de http://people.skolelinux.org/~winnie `- Debian - when you have better things to do than fixing systems signature.asc Description: This is a digitally signed message part.
Re: the new style "mass tirage" of bugs
On Wed, 2008-02-27 at 10:20 +0100, Josselin Mouette wrote: > You don’t know Jidanni, do you? It doesn't matter if I do or not. Someone who is trying to contribute shouldn't be told to piss off, or ridiculed on -devel. Doing that will drive away not only that contributor, but any potential contributors that are friends with them. William signature.asc Description: This is a digitally signed message part
Re: Google Summer of Code 2008
On Wed, 27 Feb 2008, Francesco P. Lovergine wrote: I'm not sure we will be able to reach a consensus on this, but my vote would be for this point. I'm not completely persuaded this is correct. Someone should explain why an existing contributor does not concentrate his/her efforts on the choosen project instead of wasting time in other tasks, and why a new contributor should not do that. I think it is a management problem, not a choice of contributors. I partly agree here. For instance it might be hard to find out a reasonable task that fits the skills and interests of the student out of the pure description if he is not involved in Debian before. I would not have a big problem if a non-DD (well, I agree that DDs should rather work as mentor instead as students) takes over a job in Debian that was started before but does not approach as it should be because people are occupied by other things. I would regard GSoC as a reasonable means to stress the tasks we would really like to have done and encourage people to tackle them. Did I missed something? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
On Tue February 26 2008 2:05:50 pm Ian Jackson wrote: > > It is very unfortunate for git that most of its advocates want to > adopt these almost unmanageable development practices along with the > revision control software. Yes, I agree. And even more ironic that Linus himself doesn't think that its appropriate for most projects, it appears. And moreover, that the picture that I have been getting -- and it sounds like you too -- about what is and is not acceptable in the Linux kernel development is a more nuanced than it appears. Thread at: http://thread.gmane.org/gmane.comp.version-control.git/75035 Direct link to the messages from Linus: http://article.gmane.org/gmane.comp.version-control.git/75064 http://article.gmane.org/gmane.comp.version-control.git/75083 http://article.gmane.org/gmane.comp.version-control.git/75150 but I would really suggest reading the whole thread. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Looking for co-maintainer for mercurial
On Tue February 26 2008 6:55:53 am Ondrej Certik wrote: > On Tue, Feb 26, 2008 at 1:20 AM, Edward Allcutt <[EMAIL PROTECTED]> wrote: > > > > So that would make hg the only VCS package maintained in a VCS inferior > > to itself? :P > > That's because hg-buildpackage is not really used much in Debian and > also it seems noone is interested in it much, see also this bug or > rather a wish: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=448444 > > that I reported 4 months ago with no response at all. It is a valid point that you can reconstruct the upstream branch just from the tags. But Mercurial in-tree branches are not at all the same as Git in-tree branches, and don't really lend themselves to this sort of development process as easily. In Mercurial, you are really encouraged to have the separate branches as separate dirs on disk. I think there are a few things that hg-buildpackage does which git-buildpackage doesn't yet, but nothing significant. I simply hadn't had the chance to think about that deeply yet. But I am now in the process of moving my Debian packaging work from Mercurial to Debian. If you, or someone else, would like to take over hg-buildpackage, please contact me. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#468175: ITP: pymssql -- python database access for MS SQL server and Sybase
Package: wnpp Severity: wishlist Owner: Josselin Mouette <[EMAIL PROTECTED]> * Package name: pymssql Version : 0.8.0 Upstream Author : Park joon-cheol <[EMAIL PROTECTED]> Andrzej Kukula <[EMAIL PROTECTED]> * URL : http://pymssql.sourceforge.net/ * License : LGPL Programming Lang: C, Python Description : python database access for MS SQL server and Sybase This package contains a python module allowing direct access to Microsoft SQL server and Sybase databases. It is designed for simplicity and performance, and conforms to Python DB-API 2.0. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Looking for co-maintainer for mercurial
Hi, On Wed, 2008-02-27 at 08:11 -0600, John Goerzen wrote: > On Tue February 26 2008 6:55:53 am Ondrej Certik wrote: > > On Tue, Feb 26, 2008 at 1:20 AM, Edward Allcutt <[EMAIL PROTECTED]> > wrote: > > > > > > So that would make hg the only VCS package maintained in a VCS inferior > > > to itself? :P > > > > That's because hg-buildpackage is not really used much in Debian and > > also it seems noone is interested in it much, see also this bug or > > rather a wish: > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=448444 > > > > that I reported 4 months ago with no response at all. > > It is a valid point that you can reconstruct the upstream branch just from > the tags. But Mercurial in-tree branches are not at all the same as Git > in-tree branches, and don't really lend themselves to this sort of > development process as easily. In Mercurial, you are really encouraged to > have the separate branches as separate dirs on disk. I think there are a > few things that hg-buildpackage does which git-buildpackage doesn't yet, but > nothing significant. > > I simply hadn't had the chance to think about that deeply yet. > > But I am now in the process of moving my Debian packaging work from Mercurial > to Debian. If you, or someone else, would like to take over > hg-buildpackage, please contact me. > Taking over hg-buildpackage seems interesting to me. William signature.asc Description: This is a digitally signed message part
Re: Google Summer of Code 2008
On Wed, Feb 27, 2008 at 09:42:17AM +0100, Lucas Nussbaum wrote: > (1) Forbid DDs and people in the NM process waiting for > FD/DAM to apply as students. What if we do this, and still do not get many new people applying? How about a policy of prioritising non-DD/NM/DM/whatever contributions, rather than outright forbidding established people? -- Jon Dowland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol
Package: wnpp Severity: wishlist Owner: Thorsten Schmale <[EMAIL PROTECTED]> * Package name: monkey Version : 0.9.2 Upstream Author : Eduardo Silva <[EMAIL PROTECTED]> * URL : http://monkeyd.sourceforge.net/ * License : GPL Programming Lang: C Description : monkey is a small webserver based on the HTTP/1.1 protocol Monkey is a Web Server written in C based on the HTTP/1.1 protocol. The objective is to develop a fast, efficient, small and easy to configure webserver. Although it is very small and does not need much system resources, it has a lot of nice features like Multithreading, Mimetype Support, Virtualhosts, CGI & PHP, Basic Security features (Deny by URL + IP) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Reinclusion of phpGroupware into Debian - Was: [Fwd: RFS: phpgroupware]
Hi. I has been suggested by people met at the FOSDEM this weekend, that I forward my request to -devel list, so here is it. phpGroupware was removed from Debian, and I'm proposing a new packaging (and a new maintainer) in order to have it back if possible (and on time for lenny ;). You'll find bellow the RFS I sent to -mentors list (without any response so far). PhpGroupware seems to suffer from bad reputation as far as can judge from reactions of the release and/or QA people in the live debate on Sunday, but I'd very much like to clarify the potential issues that would still be posed by this packaging, on factual basis. You may notice that we don't intend to produce official packages for things like the upstream-provided "fork" of fudforum or likely problematic apps security-wise. Many thanks in advance for your comments, help, and eventual sponsoring. Best regards, Message transféré De: Olivier Berger <[EMAIL PROTECTED]> À: [EMAIL PROTECTED] Cc: Christian BAC <[EMAIL PROTECTED]> Sujet: RFS: phpgroupware Date: Fri, 22 Feb 2008 18:31:08 +0100 Dear mentors, I am looking for a sponsor for the package "phpgroupware". * Package name: phpgroupware Version : 1:0.9.16.012+dfsg-1 Upstream Author : Multiple authors of the phpGroupware.org project + FSF (part of the GNU project) * URL : www.phpgroupware.org * License : Most under GNU GPL Section : web It builds these binary packages: phpgroupware - Web based groupware system written in PHP phpgroupware-0.9.16 - Web based groupware system written in PHP phpgroupware-0.9.16-addressbook - phpGroupWare addressbook management module phpgroupware-0.9.16-admin - phpGroupWare administration module phpgroupware-0.9.16-calendar - phpGroupWare calendar management module phpgroupware-0.9.16-core - Core applications of a groupware system based on phpGroupware phpgroupware-0.9.16-core-base - Base components of the phpGroupware application server phpgroupware-0.9.16-doc - Web based groupware system written in PHP phpgroupware-0.9.16-email - phpGroupWare E-Mail client module phpgroupware-0.9.16-filemanager - phpGroupWare filemanager module phpgroupware-0.9.16-manual - phpGroupWare on-line manual module phpgroupware-0.9.16-notes - phpGroupWare notes management module phpgroupware-0.9.16-phpgwapi - library of common phpGroupWare functions phpgroupware-0.9.16-preferences - phpGroupWare preferences management module phpgroupware-0.9.16-setup - phpGroupWare setup III module phpgroupware-0.9.16-todo - phpGroupWare todo list management module The upload would fix these bugs: 464014 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/phpgroupware - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/phpgroupware/phpgroupware_0.9.16.012+dfsg-1.dsc Note that this package is still in stable, but was removed from the distribution recently since maintainer was MIA. More details on the history of the package in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464014 and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=453467 This explains why I changed epoch. The binary packages are not as numerous as the ones in he previous package, in order to limit the amount of unmaintained or difficult to maintain code. More details are provided in the enclosed README.Debian files. Note that the binary packages contain 0.9.16 in order to prepare for potential release of phpGroupware 0.9.18 (upstream is optimistic on stabilization ofa release soon) and a coexistence period of both versions in Debian. The package's scripts or patches were not touched compared to previous packaging, and only the build process was changed to produce a different binary packages layout. Also we intend to do collaborative maintenance on the package (together with Christian Bac, in CC:, and any other volunteers), so we hope to be able to use alioth resources maybe. We hope this will help solve some of the problems that occurred on previous packaging of the software. For the records, I have no formal past track record as Debian maintainer, but I have been involved in producing local unofficial packages for our PicoForge software (www.picoforge.org), together with Christian, and am also contributing to testing and fixing bugs on the (official) Sympa package, trying to help its maintainer (racke). Besides that I'm also a Debian fan, and the BTS knows me ;) Btw, I may meet some of you this weekend at the FOSDEM, where it may be more convenient to discuss packaging of phpGroupware. Kind regards Olivier Berger -- Olivier BERGER <[EMAIL PROTECTED]> (*NEW ADDRESS*) http://www-inf.it-sudparis.eu/~olberger/ - OpenPGP-Id: 1024D/6B829EEC Ingénieur Recherche - Dept INF Institut TELECOM / TELECOM & Management SudParis (http://www.it-sudparis.eu/), Evry
Re: Google Summer of Code 2008
On Wed, Feb 27, 2008 at 9:42 AM, Lucas Nussbaum <[EMAIL PROTECTED]> wrote: > On 27/02/08 at 00:42 +, Steve McIntyre wrote: > > Hey folks, > > > > Google are running their Summer of Code programme again this year[1], > > and if we want to take part again we need to apply between March 3rd > > and March 12th. If we're accepted as a mentoring organisation, then > > students will be able to apply to work with us up until the 1st > > April. [2] > > Hi, > > I have had a problem with the way GSOC was handled in Debian in the past > years. > > Many of the students that were selected were already well-known Debian > contributors or developers. The first problem with that is that some of > those students used their GSOC time to work on their usual Debian tasks > instead of their GSOC project, leading to disapointing results, > unsuccessful projects, less projects being accepted the next year, etc. > The other problem is that some Debian developers who could have applied > as well didn't, because they thought that GSOC was only for new > contributors. > > I think that GSOC is a great opportunity to get fresh blood inside > Debian, and that we should use it for that, not to get funding for usual > Debian work. We should have a policy of not allowing existing Debian > developers to apply as students. If DDs want to use GSOC to get some > work done inside Debian, they could become mentors instead. > > However, I'm not sure that many DDs agree with this, so maybe we should > just aim for *clarification*. So any of the three following solutions > would work for me: > > (1) Forbid DDs and people in the NM process waiting for FD/DAM to apply > as students. > > (2) Make it crystal clear (through a mail to d-d-a) that DDs that are > otherwise eligible can apply as well. > > (3) Compromise: allow current contributors to apply, but, when > classifying applications, do it like that: > >1. Application from outsider >2. Application from current contributor >3. Application from outsider >4. Application from current contributor >[...] > > What do you think? I disagree with 1). Both 2) and 3) are fine with me. If some projects in the past were a failure, it is solely the problem of the management (=student's mentor:), it doesn't matter if the student was or wasn't a DD. If the student is working on something else (doesn't matter it is also related to Debian), his mentor should fail him in the middle summer evaluation. Where are the results of the last year? I only found this: http://wiki.debian.org/SummerOfCode2007 But the information about the results of each project is missing. It needs to be clear from the beginning, that if the student is not going to work on his project as written in his application (as a full time job), he will be failed. And all this information should also be available on the wiki. That wiki says Debian got over 100 applications last year - so I am 100% sure there were many students who would gladly work to meet their applications goals if they were given the chance. I suggest: * Each application needs to be a concrete plan. * Everyone is encouraged to apply. * You get many applications, both from DDs and non-DDs * you sort them from best to worst. * google assigns N slots to Debian. * You choose N students - you can choose the first N, but you can also take into account their past contributions in Debian, you can take into account that we want new blood, etc. You also take into account if there is a mentor available to mentor the application. Many factors influence the result. Disclaimer: I was a mentor last year of 2 students for the SymPy project (informally actually of 5 students, see [1]). I am in NM. And I could be a GSoC student too, but I'll be a mentor again this year for the SymPy project, if any students get accepted of course. :) Ondrej http://ondrej.certik.cz/ [1] http://code.google.com/p/sympy/wiki/GSoC2007 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Google Summer of Code 2008
Hi Patrick, * Patrick Winnertz <[EMAIL PROTECTED]> [2008-02-27 12:14]: > > > > > (1) Forbid DDs and people in the NM process waiting for FD/DAM to > > > > > apply as students. > > > > > > > > I'm not sure we will be able to reach a consensus on this, but my > > > > vote would be for this point. > > > > I'm not completely persuaded this is correct. Someone should explain > > why an existing contributor does not concentrate his/her efforts on > > the choosen project instead of wasting time in other tasks, and > > why a new contributor should not do that. I think it is a management > > problem, not a choice of contributors. > Mh.. yes this is correct. > But this is not the reason why I seconded this.. > I seconded this as the Google Summer of Code is meant for people to get in > touch with open source projects and to get new contributors. And someone > who waits for FD/DAM or is already a DD is not really new to debian. The problem with this is that the GSoC is about coding and not about contributing to a FOSS project in general. Being a DD or waiting for FD/DAM does not imply that you have experience in coding on a FOSS project. Kind regards Nico -- Nico Golde - http://www.ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. pgp4e3ucgEshe.pgp Description: PGP signature
Re: Google Summer of Code 2008
On Wed, Feb 27, 2008 at 09:42:17AM +0100, Lucas Nussbaum wrote: > On 27/02/08 at 00:42 +, Steve McIntyre wrote: > > Hey folks, > > > > Google are running their Summer of Code programme again this year[1], > > and if we want to take part again we need to apply between March 3rd > > and March 12th. If we're accepted as a mentoring organisation, then > > students will be able to apply to work with us up until the 1st > > April. [2] > > Hi, > > I have had a problem with the way GSOC was handled in Debian in the past > years. > > Many of the students that were selected were already well-known Debian > contributors or developers. The first problem with that is that some of > those students used their GSOC time to work on their usual Debian tasks > instead of their GSOC project, leading to disapointing results, > unsuccessful projects, less projects being accepted the next year, etc. > The other problem is that some Debian developers who could have applied > as well didn't, because they thought that GSOC was only for new > contributors. > > I think that GSOC is a great opportunity to get fresh blood inside > Debian, and that we should use it for that, not to get funding for usual > Debian work. We should have a policy of not allowing existing Debian > developers to apply as students. If DDs want to use GSOC to get some > work done inside Debian, they could become mentors instead. > > However, I'm not sure that many DDs agree with this, so maybe we should > just aim for *clarification*. So any of the three following solutions > would work for me: > > (1) Forbid DDs and people in the NM process waiting for FD/DAM to apply > as students. > > (2) Make it crystal clear (through a mail to d-d-a) that DDs that are > otherwise eligible can apply as well. > > (3) Compromise: allow current contributors to apply, but, when > classifying applications, do it like that: > >1. Application from outsider >2. Application from current contributor >3. Application from outsider >4. Application from current contributor >[...] > > What do you think? I noticed some of these also. IIRC most of the past GSOC people were: a) european, b) male c) existing floss contributer d) in Computer science/Informatics (stats about past demographics welcome) So, maybe prioritize people who are not these. FLOSS would benefit from more diversity. Also, GSOC mentions giving the students an opportunity to do work related to their academic pursuits and give students more exposure to real-world development environment. People who are already contributing to Debian already have 'exposure to real-world development environment'. And if someone is a current Debian contributer who joins GSOC, it should not be an existing Debian-related task unless it is related to their academic pursuit. My 2 yen, -K -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal |mysite.verizon.net/kevin.mark/| | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keyserver: subkeys.pgp.net | my NPO: cfsg.org | |join the new debian-community.org to help Debian! | |___ Unless I ask to be CCd, assume I am subscribed ___| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Google Summer of Code 2008
On 27/02/08 at 16:33 +0100, Ondrej Certik wrote: > If some projects in the past were a failure, it is solely the problem > of the management (=student's mentor:), it doesn't matter if the > student was or wasn't a DD. If the student is working on something > else (doesn't matter it is also related to Debian), his mentor should > fail him in the middle summer evaluation. What if the student worked a bit on his project, but couldn't work a lot because he was too busy working on a huge transition in Debian, or on organizing some Debian conference? You realize that such situations will never be black and white, and that failing a student (who might be a friend, or at least a fellow DD you had some beers with) is a very hard decision to take for a mentor? > That wiki says Debian got over 100 applications > last year - so I am 100% sure there were many students who would > gladly work to meet their applications goals if they were given the > chance. So there won't be a shortage of candidates, even if we decide to forbid curent contributors from applying. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Google Summer of Code 2008
On 27/02/08 at 11:33 +0100, Francesco P. Lovergine wrote: > I'm not completely persuaded this is correct. Someone should explain > why an existing contributor does not concentrate his/her efforts on > the choosen project instead of wasting time in other tasks Because all DDs are human, tend to have very large TODO list, and if given more time, tend to work on their TODO list first? I'm not saying that students that were DD did nothing of their time during GSoc, but most of them failed their projects, which defeats the purpose of GSoc, makes the GSOC organizers unhappy, and will probably cause Debian to have less slots this year again. > , and why a new contributor should not do that. I think it is a > management problem, not a choice of contributors. I agree that part of the problem is probably a management problem. However, we cannot blame the managers/mentors here: it's difficult enough to manage people working remotely, possibly in a different timezone, and for free (students are paid for their time, not their mentors). -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Google Summer of Code 2008
On 27/02/08 at 14:04 +0100, Andreas Tille wrote: > I partly agree here. For instance it might be hard to find out a > reasonable task that fits the skills and interests of the student > out of the pure description if he is not involved in Debian before. Then fix the task or its description? I'm sure we can find plenty of nice improvements to Debian that don't require very high skills or knowledge of the internals of Debian. > I would regard > GSoC as a reasonable means to stress the tasks we would really > like to have done and encourage people to tackle them. I consider that the main goal of GSOC is a social one: let new people learn about free software projects. If we start to depend on Google funding our developers through GSOC to get some important things done, that probably raises some very interesting questions. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Google Summer of Code 2008
On Wed, Feb 27, 2008 at 7:11 PM, Lucas Nussbaum <[EMAIL PROTECTED]> wrote: > On 27/02/08 at 16:33 +0100, Ondrej Certik wrote: > > If some projects in the past were a failure, it is solely the problem > > of the management (=student's mentor:), it doesn't matter if the > > student was or wasn't a DD. If the student is working on something > > else (doesn't matter it is also related to Debian), his mentor should > > fail him in the middle summer evaluation. > > What if the student worked a bit on his project, but couldn't work a lot > because he was too busy working on a huge transition in Debian, or on > organizing some Debian conference? You realize that such situations > will never be black and white, and that failing a student (who might be > a friend, or at least a fellow DD you had some beers with) is a very > hard decision to take for a mentor? Absolutely, I agree it is not black and white. But this is the responsibility of the mentor. He needs to be the one, who makes this decision and he needs to stand behind this decision. So for example if the student failed to do his GSoC project, but he organized a Debian conference and/or other things, this is what should imho be done: * the mentor should decide if he should fail him or not * at the end of the GSoC, the student (and/or mentor) should write a sum up, and this should be in the wiki. So that google and other people can see it and see for themselves, whether the $4500 from Google were justifyably spent on this project. So to answer your question - yes, I think it is perfectly possible not to do every single bit of the application, but in this case, the mentor needs to make sure he can back up his decision not to fail the student. Publicly. That's all I ask. As the outsider, all I see is this half empty wiki: http://wiki.debian.org/SummerOfCode2007 Instead, there should be reasons why each student either succeeded, or failed. Or at least some summary what each student did. The reason why I am saying this is that you are afraid of Google giving less slots each year, because the projects were a failure. > So there won't be a shortage of candidates, even if we decide to forbid > curent contributors from applying. Probably. But I don't think that restrictions of applicants can help achieve what you want (i.e. projects not being a failure). I believe in the exact opposite - allow everyone to apply, choose the best and require to fullfil the commitments as stated by the students themselves in the application. Plus showing progress of all students publicly. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Google Summer of Code 2008
On Wednesday 27 February 2008 18:52, Lucas Nussbaum wrote: > However, we cannot blame the managers/mentors here: it's difficult > enough to manage people working remotely, possibly in a different > timezone, and for free (students are paid for their time, not their > mentors). This is also a matter of policy: organisations get $500 per project, which they can decide for themselves whether or not to pass that on to individual mentors. There are quite some projects passing this $500 on to their mentors directly, and it seems well spent if that increases the success rate. Thijs pgpDYCAtoNHdO.pgp Description: PGP signature
Re: Google Summer of Code 2008
* Lucas Nussbaum ([EMAIL PROTECTED]) [080227 08:41]: > On 27/02/08 at 00:42 +, Steve McIntyre wrote: > > Hey folks, > > > > Google are running their Summer of Code programme again this year[1], > > and if we want to take part again we need to apply between March 3rd > > and March 12th. If we're accepted as a mentoring organisation, then > > students will be able to apply to work with us up until the 1st > > April. [2] > > Hi, > > I have had a problem with the way GSOC was handled in Debian in the past > years. so has someone noticed that in contrast to earlier years 100% of the projects assigned to us also finished? I know that among Google itself looks at that number. There is something to be said for people who know the setting they are going to work in. Debian being special and friendly and all could be a huge dissappointment for all those that think they can pick a fight here or start flamewars. :-) /andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Google Summer of Code 2008
> > I would regard > > GSoC as a reasonable means to stress the tasks we would really > > like to have done and encourage people to tackle them. > > I consider that the main goal of GSOC is a social one: let new people > learn about free software projects. If we start to depend on Google > funding our developers through GSOC to get some important things done, > that probably raises some very interesting questions. Yes, I completely agree with this. Yet my solution is not to restrict the applicants, but rather to demand to follow their own applications, otherwise failing them. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: On the subject of watchfiles (was Re: Proposed MBF: Debian upstream version higher than watch file-reported upstream version)
Andreas Tille dijo [Tue, Feb 26, 2008 at 08:21:47PM +0100]: > >Heh, start a bit earlier (think Ruby)... Educate maintainers to > >release proper .tar.gz, not braindead .gem packages containing the > >equivalent to an orig.tar.gz (but created due to a nice > >don't-ask-me-why-that's-not-properly-implemented bug in December 31, > >1969)... And then complaining if you are distributing in stable > >anything older than their nightly checkouts. > > > >Yes, Perl and the CPAN rock my world, although my programming is > >nowadays mostly Ruby-based. The Ruby general mindset is WAY inferior. > > What? > I admit I would have been able to parse the contents of your mail > with the same success if you would have written in Spanish. :) > Prehaps it is me who had to get up 4:20 this morning (so I started > *really* early ;-) ) - but I do not even understand whether this is pro or > contra proper watch files. Sorry, I'm a bit incoherent as well - due to all kind of unrelated events :) I'm completely pro-watch. It is fundamental to the way pkg-perl works. As said IIRC by Tincho, there is no way to keep track of over 670 packages without automated tools. What really brings me down is that this is impossible in communities such as the Ruby one, which uses a incoherent and brain-dead packaging format, and insists on shoving it on distributions' throats. Bah. -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol
On Wed, Feb 27, 2008 at 03:51:38PM +0100, Thorsten Schmale wrote: > * Package name: monkey > Description : monkey is a small webserver based on the HTTP/1.1 protocol Don't include the name of the package in the short description. Also, "HTTP/1.1 protocol" is more something for the long description. Description: light-weight web server > Monkey is a Web Server written in C based on the HTTP/1.1 protocol. The > objective is to develop a fast, efficient, small and easy to configure > webserver. > Although it is very small and does not need much system resources, it > has a lot of nice features like Multithreading, Mimetype Support, > Virtualhosts, CGI & PHP, Basic Security features (Deny by URL + IP) The language the server is written in is not important. Use the debtags system to annotate the package with that kind of information. Also, don't use subjective wording like "nice features". There are also too much capitals in your description. I suggest the following: Monkey is a small, fast, and easily configurable HTTP/1.1 compliant web server. It uses multi-threading and has support for MIME, virtual hosts, CGI and PHP. It offers basic security features, such as denying access to certain URLs for certain IP addresses. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Google Summer of Code 2008
On Wed, Feb 27, 2008 at 06:52:56PM +0100, Lucas Nussbaum wrote: > On 27/02/08 at 11:33 +0100, Francesco P. Lovergine wrote: > > I'm not completely persuaded this is correct. Someone should explain > > why an existing contributor does not concentrate his/her efforts on > > the choosen project instead of wasting time in other tasks > Because all DDs are human, tend to have very large TODO list, and if > given more time, tend to work on their TODO list first? I'm not saying > that students that were DD did nothing of their time during GSoc, but > most of them failed their projects, which defeats the purpose of GSoc, > makes the GSOC organizers unhappy, and will probably cause Debian to > have less slots this year again. Er, by what metric have these students "failed" their projects? The summer has finished, and it's about time I summarised how we got on. We had 9 Summer of Code students working for us, and we had a 100% success rate this year. Woo! Last year we only managed 6 successful projects out of 10, so that's a major improvement. http://lists.debian.org/debian-devel-announce/2007/10/msg1.html I really can't figure out what you're saying, here. AFAICS, we had significantly *better* results when choosing GSoC projects submitted by existing Debian contributors. Where are these failures you're talking about? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Google Summer of Code 2008
> Er, by what metric have these students "failed" their projects? > > The summer has finished, and it's about time I summarised how we got > on. We had 9 Summer of Code students working for us, and we had a 100% > success rate this year. Woo! Last year we only managed 6 successful > projects out of 10, so that's a major improvement. > > http://lists.debian.org/debian-devel-announce/2007/10/msg1.html Excellent, that email is exactly what I was looking for. I added it to the wiki: http://wiki.debian.org/SummerOfCode2007 Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#468221: ITP: missidentify -- a program to find win32 applications
Package: wnpp Severity: wishlist Owner: Debian Forensics <[EMAIL PROTECTED]> X-Debbugs-CC: debian-devel@lists.debian.org Package name: missidentify Version: 1.0 Upstream Author: Jesse Kornblum URL: http://missidentify.sourceforge.net] License: GPL-2+] Description: a program to find win32 applications Miss Identify is a program to find Win32 applications. In its default mode it displays the filename of any executable that does not have an executable extension (i.e. exe, dll, com, sys, cpl, hxs, hxi, olb, rll, or tlb). The program can also be run to display all executables encountered, regardless of the extension. This is handy when looking for all of the executables on a drive. Other options allow the user to record the strings found in an executable and to work recursively -- Christophe Monniez -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#468221: ITP: missidentify -- a program to find win32 applications
On Wed, Feb 27, 2008 at 09:07:33PM +0100, Monniez Christophe wrote: Miss Identify is a program to find Win32 applications. In its default mode it displays the filename of any executable that does not have an executable extension (i.e. exe, dll, com, sys, cpl, hxs, hxi, olb, rll, or tlb). The program can also be run to display all executables encountered, regardless of the extension. This is handy when looking for all of the executables on a drive. Other options allow the user to record the strings found in an executable and to work recursively What does this do that file(1) does not? lakeview ok % file setup.exe setup.exe: MS-DOS executable PE for MS Windows (GUI) Intel 80386 32-bit, UPX compressed -- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Google Summer of Code 2008
On 27/02/2008, Lucas Nussbaum wrote: > Many of the students that were selected were already well-known > Debian contributors or developers. The first problem with that is > that some of those students used their GSOC time to work on their > usual Debian tasks instead of their GSOC project, leading to > disapointing results, unsuccessful projects, less projects being > accepted the next year, etc. Nice claims. Pointers? > (1) Forbid DDs and people in the NM process waiting for FD/DAM to > apply as students. How is this distinction relevant? Isn't that possible to be waiting-for-that-never-coming-DAM-review, student, but also working on various opensource projects, as well as maintaining packages, alone or within teams, working on various areas of the Debian project (e.g. QA, by providing with patches, NMUing packages; or mentoring people with their new or updated packages), at the very same time? I believe it's possible. And I believe you'll find a trivial example. Now. How come it wouldn't be possible to apply for a GSOC slot, lowering the involvement in one (or more) of the above-mentioned areas, and concentrating on a specific project? -- Cyril Brulebois pgpYW2fuA7IMK.pgp Description: PGP signature
Re: Bug#468132: ITP: packagekit [...]
Am Mittwoch, den 27.02.2008, 11:28 +0100 schrieb Guus Sliepen: > On Wed, Feb 27, 2008 at 08:53:04AM +0100, Sebastian Heinlein wrote: > > > * Package name: packagekit > > Description : PackageKit provides a distribution neutral interface to > > manage software packages. It provides a system wide daemon that performs > > tasks like refreshing the cash, updating, installing and removing software > > independetly from the user interface. By default, PackageKit uses PolicyKit > > for user authentication. This allows to specify with fine-grained control > > what your users can and cannot do. > > > > (Include the long description here.) > > Debian packages have both a short description and a long one. I also see > you made some spelling errors. I suggest the following short and long > description: > > Description: distribution neutral software package manager > PackageKit provides a distribution neutral interface to manage > software packages. It provides a daemon that refreshes the package > cache, updates, installs and removes packages independent of the user > interface. > . > By default, PackageKit uses PolicyKit to provide fine-grained access > control. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed MBF: Debian upstream version higher than watch file-reported upstream version
Hello Jörg, Jörg Sommer wrote: > Hello Raphael, > > Raphael Geissert <[EMAIL PROTECTED]> wrote: >> Jörg Sommer <[EMAIL PROTECTED]> >>jed (U) > > This is a SVN snapshot. There's no release of it. I fail to see how to > point to a changelog file in a SVN repository. How should I handle this > situation? By making me ignore those watch file which are in experimental? :) > > Bye, Jörg. Cheers, Raphael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#468267: ITP: edje -- Graphical layout and animation library
Package: wnpp Severity: wishlist Owner: Jan Luebbe <[EMAIL PROTECTED]> * Package name: edje Version : 0.5.0.042 Upstream Author : Carsten Haitzler and the e17 devel team <[EMAIL PROTECTED]> * URL : http://www.enlightenment.org * License : BSD Programming Lang: C Description : Graphical layout and animation library Edje is a graphical layout and animation library for animated resizable, compressed and scalable themes. It is the theming engine behind Enlightenment DR 0.17. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (900, 'unstable'), (300, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-x60s (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#468268: ITP: edbus -- D-Bus integration for EFL based applications
Package: wnpp Severity: wishlist Owner: Jan Luebbe <[EMAIL PROTECTED]> * Package name: edbus Version : 0.1.0.042 Upstream Author : Carsten Haitzler and the e17 devel team <[EMAIL PROTECTED]> * URL : http://www.enlightenment.org * License : BSD Programming Lang: C Description : D-Bus integration for EFL based applications This library integrates libdbus with the ecore mainloop and provides some additional helper functions. It is used by the Enlightenment DR17 desktop. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (900, 'unstable'), (300, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-x60s (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#468269: ITP: embryo -- SMALL-based abstract machine (AMX) bytecode interpreter
Package: wnpp Severity: wishlist Owner: Jan Luebbe <[EMAIL PROTECTED]> * Package name: embryo Version : 0.9.1.042 Upstream Author : Carsten Haitzler and the e17 devel team <[EMAIL PROTECTED]> * URL : http://www.enlightenment.org * License : BSD Programming Lang: C Description : SMALL-based abstract machine (AMX) bytecode interpreter Embryo is primarily a shared library that gives you an API to load and control interpreted programs compiled into an abstract machine bytecode that it understands. This abstract (or virtual) machine is similar to a real machine with a CPU, but it is emulated in software. The architecture is simple and is the same as the abstract machine (AMX) in the SMALL language as it is based on exactly the same code. Embryo has modified the code for the AMX extensively and has made it smaller and more portable. It is VERY small. The total size of the virtual machine code AND header files is less than 2500 lines of code. It includes the floating point library support by default as well. This makes it one of the smallest interpreters around, and thus makes is very efficient to use in code. See also http://www.compuphase.com/small.htm for details on SMALL. It is used in the Enlightenment DR17 desktop. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (900, 'unstable'), (300, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-x60s (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#468287: ITP: dkimproxy -- an SMTP-proxy that signs and/or verifies emails, using the Mail::DKIM module
Package: wnpp Severity: wishlist Owner: Thomas GOIRAND <[EMAIL PROTECTED]> * Package name: dkimproxy Version : x.y.z Upstream Author : Jason Long <[EMAIL PROTECTED]> * URL : http://dkimproxy.sourceforge.net/ * License : GPL v2 Programming Lang: Perl Description : an SMTP-proxy that signs and/or verifies emails, using the Mail::DKIM module DKIMproxy is an SMTP-proxy that signs and/or verifies emails, using the Mail::DKIM module. It is designed for Postfix, but should work with any mail server. It comprises two separate proxies, an "outbound" proxy for signing outgoing email, and an "inbound" proxy for verifying signatures of incoming email. With Postfix, the proxies can operate as either Before-Queue or After-Queue content filters. - Maintainer's note: Note that after this package is upload, I can also upload a new version of dtc that will use it instead of dkfilter, and then I will ask for removal of dkfilter that is has been superceded by dkimproxy. FYI, See this bug in the BTS as well: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468192 -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (700, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.23.9 Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#468290: ITP: mozilla-dom-inspector -- tool for inspecting the DOM of pages in Mozilla-based browsers
Package: wnpp Severity: wishlist Owner: Mike Hommey <[EMAIL PROTECTED]> * Package name: mozilla-dom-inspector Version : ?? Upstream Author : Mozilla Foundation * URL : https://addons.mozilla.org/en-US/firefox/addon/6622 * License : MPL/GPL/LGPL Programming Lang: Javascript Description : tool for inspecting the DOM of pages in Mozilla-based browsers Current mozilla trunk doesn't bundle the DOM inspector with Firefox and friends anymore, which means we'll have to make it an external package soon. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Google Summer of Code 2008
On 27/02/08 at 18:51 +0100, Ondrej Certik wrote: > Absolutely, I agree it is not black and white. But this is the > responsibility of the mentor. He needs to be the one, who makes this > decision and he needs to stand behind this decision. I don't know if that's allowed by GSOC, but taking the final success/fail decision as a group (with some sort of comittee) could really help avoid this dilemma. Seriously, I would hate to be a mentor and have to decide whether I can give $2000 to $STUDENT who: * is an active Debian contributor * did a few things on his project * but clearly didn't do everything that was expected, and didn't work fulltime on it > So for example if the student failed to do his GSoC project, but he > organized a Debian conference and/or other things, this is what should > imho be done: > > * the mentor should decide if he should fail him or not > * at the end of the GSoC, the student (and/or mentor) should write a > sum up, and this should be in the wiki. So that google and other > people can see it and see for themselves, whether the $4500 from > Google were justifyably spent on this project. > > So to answer your question - yes, I think it is perfectly possible not > to do every single bit of the application, but in this case, the > mentor needs to make sure he can back up his decision not to fail the > student. Publicly. Full ACK. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Google Summer of Code 2008
On 27/02/08 at 11:26 -0800, Steve Langasek wrote: > On Wed, Feb 27, 2008 at 06:52:56PM +0100, Lucas Nussbaum wrote: > > On 27/02/08 at 11:33 +0100, Francesco P. Lovergine wrote: > > > I'm not completely persuaded this is correct. Someone should explain > > > why an existing contributor does not concentrate his/her efforts on > > > the choosen project instead of wasting time in other tasks > > > Because all DDs are human, tend to have very large TODO list, and if > > given more time, tend to work on their TODO list first? I'm not saying > > that students that were DD did nothing of their time during GSoc, but > > most of them failed their projects, which defeats the purpose of GSoc, > > makes the GSOC organizers unhappy, and will probably cause Debian to > > have less slots this year again. > > Er, by what metric have these students "failed" their projects? > > The summer has finished, and it's about time I summarised how we got > on. We had 9 Summer of Code students working for us, and we had a 100% > success rate this year. Woo! Last year we only managed 6 successful > projects out of 10, so that's a major improvement. > > http://lists.debian.org/debian-devel-announce/2007/10/msg1.html > > I really can't figure out what you're saying, here. AFAICS, we had > significantly *better* results when choosing GSoC projects submitted by > existing Debian contributors. Where are these failures you're talking > about? My definition of failure is: "(what was achieved) < (what I expected to be achieved, given the skills of the people assigned and the time they were supposed to spend on the project)". That's of course subjective, but I think that the evaluation done by the mentors is subjective too. How were the GSOC projects evaluated? Were they given goals to fullfill? We probably need to improve the descriptions of the projects a bit, so people know a bit more what they are expected to do. Also, as I said earlier, in some cases, the mentor might have had a very difficult decision about failing (or not) the student, since the student is probably a friend, who might have badly needed the money, etc. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Google Summer of Code 2008
On 27/02/08 at 22:00 +0100, Cyril Brulebois wrote: > On 27/02/2008, Lucas Nussbaum wrote: > > Many of the students that were selected were already well-known > > Debian contributors or developers. The first problem with that is > > that some of those students used their GSOC time to work on their > > usual Debian tasks instead of their GSOC project, leading to > > disapointing results, unsuccessful projects, less projects being > > accepted the next year, etc. > > Nice claims. Pointers? I agree that this is mainly based on personal perception (but that's not really my fault: no final report about what students did (in detail) are available). > > (1) Forbid DDs and people in the NM process waiting for FD/DAM to > > apply as students. > > How is this distinction relevant? Isn't that possible to be > waiting-for-that-never-coming-DAM-review, student, but also working on > various opensource projects, as well as maintaining packages, alone or > within teams, working on various areas of the Debian project (e.g. QA, > by providing with patches, NMUing packages; or mentoring people with > their new or updated packages), at the very same time? > > I believe it's possible. And I believe you'll find a trivial example. GSOC != "get funding for existing DDs to do $DEBIAN_WORK". If GSOC is only DuncTank 2.0, I think that we could have a nice thread^Hflamewar about whether it's good or evil. GSOC is considered good by many people because one of its stated goals is to bring fresh blood to free software. Now, I agree that "fresh blood" is difficult to define. Is someone that has been involved a bit in Debian for 1-2 months "fresh blood"? Someone who submitted some bug reports, but never got involved? someone who is very involved in GNOME, but not involved in Debian? So my distinction sucks, but I couldn't come up with something better that fitted in a line. > Now. How come it wouldn't be possible to apply for a GSOC slot, > lowering the involvement in one (or more) of the above-mentioned > areas, and concentrating on a specific project? Past years show that this is very hard to do, but of course it's possible. But that also means that we are shooting ourselves in the foot: we are asking someone to lower his involvement in some areas of Debian, where we might be depending on him. Many Debian teams might not be able to afford to lose an active contributor during the summer (just before the lenny release!) so he can work on his GSOC project. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
