Re: Re: Google Summer of Code 2009: Debian's Shortlist
On 2009-04-11, Filipus Klutiero chea...@gmail.com wrote: Obey Arthur Liu wrote: === And the details: === [...] These descriptions are very short. Assuming these are the abstracts, that's not the students' fault. The abstracts were shortened this year to 500 characters. I struggled to shorten mine to fit this. At this length, it's probably impossible to fit a decent summary of most projects. It would normally make sense to use abstracts for this use case. Maybe Google should be asked to change the limit. Otherwise I'd like to see a custom description which describes a little further. I currently can't comment on all projects presented. That said, this shortlist remains useful, and I thank you for this great jump in transparency. Mind to tell us what your proposed project was? For more transparency? Kind regards, Philipp Kern Here is my application, stripped only from the personal section. I will not submit this idea anymore. Students should feel free to use this application as they wish. The project needs a student with a good understanding of Debian package management. Most importantly, a mentor familiar with APT should be found. This was a very scarce resource in the last 3 years. = Project Title = Improved package management of language packs = Origins = There are currently two methods to distribute localized data: * Bundling localized data for all languages with the application package. The main issue with this approach is the size of the package. * Architecture-independent packages associated with the application packages providing localized data. There is typically one package per language. Since they 'enable' the language translation for that software when installed they are called language packages or language packs. The main issue with this approach is that the language package for an application is not installed automatically. The first method is suboptimal while the second is less usable. For more information, see http://wiki.debian.org/i18n/TranslationDataDistribution/Chealer = Project = The intention is to optimize distribution of localized data by improving the usability of the second method, which should encourage its use and diminish the usage of the first method. Concretely, the first goal is that installation of language packs happens automatically. For example, French people should get openoffice.org-l10n-fr installed automatically when openoffice.org is installed. The second goal is to control the effects of growing the number of packages. The growth of the Packages file and the number of packages returned by searches should be avoided or limited. = Benefits to Debian = The Debian groups which would benefit from this project are users and mirror providers. Administrators of non-English systems are particularly targeted. == Direct benefits (improvements to language packs handling) == The first direct benefit to users is that administrators will no longer need to specifically select the language packages they want to install in order to make translations available. The second direct benefit is that the size of Packages and the number of packages matching a search should be reduced. Note that the actual secondary direct benefits will depend on how exactly controlling the effects of growing the number of packages will be done. == Indirect benefits (avoiding packages bundling l10n data) == The indirect benefit of this project is that increasing the interest in language packs should reduce the number of application packages bundling localized data. Concretely, the issues of this method will be avoided: * Localized data increases (for all architectures) the binary package size. * On multi-architecture mirrors, architecture-specific packages increase disk usage and bandwidth usage for synchronizations. * Increases bandwidth usage for users and uploading mirrors. * Increases disk space usage for users. localepurge, considered a hack, exists to diminish this issue. * Time for installs is increased due to getting and unpacking a larger .deb. * Localized data is in the same binary package and therefore has to be built from the same source package as the application. * Localized data can not be handled by different maintainers. * Translation updates can not be made independently from the application binary package and could cause a regression in the application package. It is risky to do translation updates during a freeze. * A translation update means that the application binary package needs to be rebuilt. This causes larger updates (mostly more bandwidth usage) and increased buildd usage, so maintainers tend to wait for a new software release before providing the translation updates. The delay for translator's work to reach users tends to increase (e.g. debconf updates sitting in the BTS). Work from maintainers will be needed to obtain these indirect benefits. Nevertheless, I expect the indirect
Re: KDE/Qt Package Manager (Re: Google Summer of Code 2009: Debian's Shortlist)
I have no issue with Adept, and I would love to see a good Qt/KDE package manager, but if we're to get KPackageKit, I'd like to be sure that we won't sponsor yet another APT front-end that won't be used. Still, it remains the aptitude-qt solution. But it seems aptitude code is tighten with the gtk backend and extending it to add the qt backend cannot be done now. Does it make sense to finish Adept3 when it can(should?) be superseeded later by aptitude ? Why not finish aptitude-gtk separation then properly add qt pieces ? please note that I never looked aptitude source code. cheers, Fathi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: KDE/Qt Package Manager (Re: Google Summer of Code 2009: Debian's Shortlist)
Fathi Boudra a écrit : I have no issue with Adept, and I would love to see a good Qt/KDE package manager, but if we're to get KPackageKit, I'd like to be sure that we won't sponsor yet another APT front-end that won't be used. Still, it remains the aptitude-qt solution. But it seems aptitude code is tighten with the gtk backend and extending it to add the qt backend cannot be done now. Does it make sense to finish Adept3 when it can(should?) be superseeded later by aptitude ? aptitude-qt would not be possible before squeeze. That would leave us with no usable Qt4 package manager. Why not finish aptitude-gtk separation then properly add qt pieces ? Another strategy is to replace the adept/ept backend of adept 3.0 with the aptitude backend once it is transformed into a library. It seems to have become some sort of habit for aptitude to explore new features before having them ported back to the common apt code. Cheers Arthur -- Obey Arthur Liu http://www.milliways.fr signature.asc Description: OpenPGP digital signature
Re: Google Summer of Code 2009: Debian's Shortlist
On 2009-04-11, Filipus Klutiero chea...@gmail.com wrote: Obey Arthur Liu wrote: === And the details: === [...] These descriptions are very short. Assuming these are the abstracts, that's not the students' fault. The abstracts were shortened this year to 500 characters. I struggled to shorten mine to fit this. At this length, it's probably impossible to fit a decent summary of most projects. It would normally make sense to use abstracts for this use case. Maybe Google should be asked to change the limit. Otherwise I'd like to see a custom description which describes a little further. I currently can't comment on all projects presented. That said, this shortlist remains useful, and I thank you for this great jump in transparency. Mind to tell us what your proposed project was? For more transparency? Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Google Summer of Code 2009: Debian's Shortlist
Hi! On Fri, 2009-04-10 at 09:18:32 +0200, Obey Arthur Liu wrote: === And the details: === * Control Files Parsing/Editing Library/Qt4-Debconf Qt4-Perl bindings * --- Student: Jonathan Yu, Mentor: (probably) Dominique Dumont *see below* This project proposes a common library for parsing and manipulating Debian Control files, including control, copyright and changelog. Main ideas include validating and parsing of these files, with both Strict and Quirks modes for the parser. The second idea is a new frontend for Debconf using Qt4 (for which Perl bindings will be written). I've some comments after checking the more detailed project proposal at: http://wiki.debian.org/jawnsy/Debian_Control_Files_Parsing_and_Editing_Library There's already several libraries to parse debian control and changelog files, but I don't think there's anything for copyright as the format is not yet standardized. dpkg has a C library (albeit not yet public) for parsing and dumping control-style files, and dpkg-dev has also perl modules supporting control and changelog files. I'm also aware of apt's implementation in C++, and there's others in python, ruby, etc. There's also mention of rewritting debconf in C/C++, but that has also already been done in the form of cdebconf. regards, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Google Summer of Code 2009: Debian's Shortlist
On Fri, Apr 10, 2009 at 7:38 AM, Raphael Hertzog hert...@debian.org wrote: * Debbugs Web UI: Amancay Strikes Back * Student: Diego Escalante Urrelo, Mentor: Margarita Manterola The Amancay project aims to be a new read/write web frontend to Debian's BTS; allowing DDs and contributors to easily interact with bugs via an intuitive yet powerful interface, enabling new workflows and creating new contribution opportunities like triaging while upholding reporting quality. IMO it's important to have some web UI but we already had a project for this IIRC and it was not very successful. It would be interesting to know how the approach followed this year will differ from last time so that we have some good results this time. The project wasn't successful because I ran out of time and then had a myriad of other things to do. But extending the code that is already there instead of starting from scratch, and the fact that we will both be working on the code, will allow us to finish it this time, and hopefully have it online at some debian.net location by the end of the summer. -- Besos, Marga -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Google Summer of Code 2009: Debian's Shortlist
Obey Arthur Liu wrote: === And the details: === [...] These descriptions are very short. Assuming these are the abstracts, that's not the students' fault. The abstracts were shortened this year to 500 characters. I struggled to shorten mine to fit this. At this length, it's probably impossible to fit a decent summary of most projects. It would normally make sense to use abstracts for this use case. Maybe Google should be asked to change the limit. Otherwise I'd like to see a custom description which describes a little further. I currently can't comment on all projects presented. That said, this shortlist remains useful, and I thank you for this great jump in transparency. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
KDE/Qt Package Manager (Re: Google Summer of Code 2009: Debian's Shortlist)
Obey Arthur Liu wrote: * KDE/Qt4 Adept 3.0 Package Manager * - Student: Mateusz Marek, Mentor: *NEEDS MENTOR, see below.* Finish Adept 3.0, a fully integrated package manager for Qt4/KDE4. Adept is currently the only viable path to a Debian native package manager on KDE that would support modern features such as tags, indexed search or good conflict resolving. With Aptitude-gtk still in development and only available for GTK+ and (K)PackageKit having fundamental problems, Debian needs this project to stay in control of its package management on KDE after much neglect in the recent years. At the risk of repeating myself, what are the fundamental problems in (K)PackageKit? I have no issue with Adept, and I would love to see a good Qt/KDE package manager, but if we're to get KPackageKit, I'd like to be sure that we won't sponsor yet another APT front-end that won't be used. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: KDE/Qt Package Manager (Re: Google Summer of Code 2009: Debian's Shortlist)
On 2009-04-11, Filipus Klutiero chea...@gmail.com wrote: Obey Arthur Liu wrote: * KDE/Qt4 Adept 3.0 Package Manager * - Student: Mateusz Marek, Mentor: *NEEDS MENTOR, see below.* Finish Adept 3.0, a fully integrated package manager for Qt4/KDE4. Adept is currently the only viable path to a Debian native package manager on KDE that would support modern features such as tags, indexed search or good conflict resolving. With Aptitude-gtk still in development and only available for GTK+ and (K)PackageKit having fundamental problems, Debian needs this project to stay in control of its package management on KDE after much neglect in the recent years. At the risk of repeating myself, what are the fundamental problems in (K)PackageKit? I have no issue with Adept, and I would love to see a good Qt/KDE package manager, but if we're to get KPackageKit, I'd like to be sure that we won't sponsor yet another APT front-end that won't be used. As far as I understood it, PackageKit has no back and forth communication with the user about what to (not) install. You can tell packagekit to install/remove a package, but unless you implement full dependency resolution in the packagekit frontend, you can't properly figure out what to (not) do. And if dependency resolution is to happen in the frontend as well, then packagekit lost all it's theoretical advantages. Beside that, it answers 'no' to all dpkg conffile prompts, and interaction with debconf looks like more a hack than a real solution. Oh. and then, packagekit is made to give users the ability to install a few packages on their own, not to do full package administration. /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Google Summer of Code 2009: Debian's Shortlist
On Fri, 10 Apr 2009, Obey Arthur Liu wrote: === Debian's Shortlist: === = My own shortlist of projects out of those that you have retained is the following: - Port back update-manager to Debian and all Derivatives - Debbugs Web UI: Amancay Strikes Back - Automatic Debug Packages Creation and Handling Those 3 projects are IMO important improvements that we definitely need. - Debian Autobuilding Infrastructure Rewrite - Debian-Installer Support for GNU/kFreeBSD - MTD Embedded Onboard flash Partitioning and Installation - Aptitude Package Management History Tracking Those 4 are very nice to have and I would like to see them completed. - Control Files Parsing/Editing Library/Qt4-Debconf Qt4-Perl bindings - KDE/Qt4 Adept 3.0 Package Manager - Large Scientific Dataset Package Management - MIPS N32 ABI Port - On-demand Cloud Computing with Amazon EC2 and Eucalyptus Integration I don't care very much about those. The last one might be interesting though. * Automatic Debug Packages Creation and Handling * -- Student: Emilio Pozuelo Monfort, Mentor: Marc Brockschmidt This proposal aims at providing debug binary packages for the packages in the Debian archive in an automatic manner, moving them away from the official Debian archive to an special one. This has the benefits of providing thousands of debug packages without any work needed from the developers, for all the architectures, without bloating the archive. I thought that Marc was not able to mentor this one. Did he change his mind ? * Debbugs Web UI: Amancay Strikes Back * Student: Diego Escalante Urrelo, Mentor: Margarita Manterola The Amancay project aims to be a new read/write web frontend to Debian's BTS; allowing DDs and contributors to easily interact with bugs via an intuitive yet powerful interface, enabling new workflows and creating new contribution opportunities like triaging while upholding reporting quality. IMO it's important to have some web UI but we already had a project for this IIRC and it was not very successful. It would be interesting to know how the approach followed this year will differ from last time so that we have some good results this time. * Debian-Installer Support for GNU/kFreeBSD * - Student: Luca Favatella, Mentor: Aurelien Jarno GNU/kFreeBSD is currently using a hacked version of the FreeBSD installer combined with crosshurd as its own installer. While this works more or less correctly for standard installations (read: the exact same installation as in the documentation), it does not allow any changes in the installation process except the hard disk partitioning. This project is about porting debian-installer on GNU/kFreeBSD, and to a bigger extent, make debian-installer less Linux dependant. I imagine that this will be a big work. My fear is that it would make it even more difficult to maintain d-i. Also given the individuals in the d-i team, one should pay attention to involve the d-i teams in the design quite early on. * On-demand Cloud Computing with Amazon EC2 and Eucalyptus Integration * Student: David Wendt Jr, Mentor: (probably) Steffen Moeller *see below* In many academic fields, as well as commercial industries, people use clusters to distribute tasks among multiple machines. Many times this is done by packaging a whole operating system disk image, uploading it onto the cluster, and having the cluster run it in a VM. This project intends to make it easier for Debian to distribute prepared disk images templates like they distribute CD images now, for the users to recreate or customise these templates with Debian packages and for administrators to host such clusters with Debian. I wonder what the challenges are… or is it simply about an UI that wraps deboostrap and some loop-mounting of filesystem images ? * Port back update-manager to Debian and all Derivatives * -- Student: Stephan Peijnik, Mentor: Michael Vogt The project would involve taking the distribution-(Ubuntu-)specific update-manager code, analyzing it, and creating a package with just its core functionality, decoupling the distribution-specific parts and thus making the core code extensible by distribution-specific add-ons. This in turn would remove the need of porting update-manager to Debian with every upstream release. An additional optional goal would be replacing the synaptics-backend with a python-apt based one. It would also be particularly interesting to try to write the code corresponding to the lenny upgrade notes so that we can make use of the distribution upgrade feature for novice users that don't read the release notes. * Debian Autobuilding Infrastructure
Re: Google Summer of Code 2009: Debian's Shortlist
Le vendredi 10 avril 2009 à 12:38 +0200, Raphael Hertzog a écrit : * Automatic Debug Packages Creation and Handling * -- Student: Emilio Pozuelo Monfort, Mentor: Marc Brockschmidt This proposal aims at providing debug binary packages for the packages in the Debian archive in an automatic manner, moving them away from the official Debian archive to an special one. This has the benefits of providing thousands of debug packages without any work needed from the developers, for all the architectures, without bloating the archive. I thought that Marc was not able to mentor this one. Did he change his mind ? After discussing this a bit with Emilio, I’d agree to mentor or co-mentor this project. -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Google Summer of Code 2009: Debian's Shortlist
On 2009-04-10, Raphael Hertzog hert...@debian.org wrote: * Debian Autobuilding Infrastructure Rewrite * -- Student: Philipp Kern, Mentor: Luk Claes Rewrite the software that currently runs the Debian autobuilding infrastructure in a way that makes it more maintainable and robust. It will use Python as its programming language and PostgreSQL for the database backend. By harmonizing buildds, many build failures can be prevented and wasteful workload on buildd volunteers can be reduced. What parts are concerned and how will it work out with Roger Leigh ? Will he be involved or not ? I remember that among the rules the student should work alone on the code, he should not have external help so that the result can be judged as being his work. Would it be problematic in this case ? The complete proposal is available here: http://socghop.appspot.com/document/show/user/pkern/wb_python Sadly proposals are not publically viewable so this is a copy I kept in my personal namespace during its development. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Google Summer of Code 2009: Debian's Shortlist
Raphael Hertzog a écrit : Hi Raphael and thanks for your mail. On Fri, 10 Apr 2009, Obey Arthur Liu wrote: * Automatic Debug Packages Creation and Handling * -- Student: Emilio Pozuelo Monfort, Mentor: Marc Brockschmidt This proposal aims at providing debug binary packages for the packages in the Debian archive in an automatic manner, moving them away from the official Debian archive to an special one. This has the benefits of providing thousands of debug packages without any work needed from the developers, for all the architectures, without bloating the archive. I thought that Marc was not able to mentor this one. Did he change his mind ? Marc was put as a placeholder. Josselin Mouette is now the mentor. * Debbugs Web UI: Amancay Strikes Back * Student: Diego Escalante Urrelo, Mentor: Margarita Manterola The Amancay project aims to be a new read/write web frontend to Debian's BTS; allowing DDs and contributors to easily interact with bugs via an intuitive yet powerful interface, enabling new workflows and creating new contribution opportunities like triaging while upholding reporting quality. IMO it's important to have some web UI but we already had a project for this IIRC and it was not very successful. It would be interesting to know how the approach followed this year will differ from last time so that we have some good results this time. You should ask Marga about this but OTOH, I remember there were issues with Django not being mature enough two years ago (Django has reached 1.0 since), python-bts not being there yet and the scope of the project being quite large.. * On-demand Cloud Computing with Amazon EC2 and Eucalyptus Integration * Student: David Wendt Jr, Mentor: (probably) Steffen Moeller *see below* In many academic fields, as well as commercial industries, people use clusters to distribute tasks among multiple machines. Many times this is done by packaging a whole operating system disk image, uploading it onto the cluster, and having the cluster run it in a VM. This project intends to make it easier for Debian to distribute prepared disk images templates like they distribute CD images now, for the users to recreate or customise these templates with Debian packages and for administrators to host such clusters with Debian. I wonder what the challenges are… or is it simply about an UI that wraps deboostrap and some loop-mounting of filesystem images ? The proposal lives here: http://wiki.debian.org/DavidWendt/GSOCProposal There a decent quantity of work, having both Amazon EC2 and Eucalyptus developers on board. * Debian Autobuilding Infrastructure Rewrite * -- Student: Philipp Kern, Mentor: Luk Claes Rewrite the software that currently runs the Debian autobuilding infrastructure in a way that makes it more maintainable and robust. It will use Python as its programming language and PostgreSQL for the database backend. By harmonizing buildds, many build failures can be prevented and wasteful workload on buildd volunteers can be reduced. What parts are concerned and how will it work out with Roger Leigh ? Will he be involved or not ? Phil posted his proposal here: http://socghop.appspot.com/document/show/user/pkern/wb_python I remember that among the rules the student should work alone on the code, he should not have external help so that the result can be judged as being his work. Would it be problematic in this case ? There's no such rule. The only common sense rule is that we should distinguish his commits, which is quite easy. Cheers Arthur -- Obey Arthur Liu http://www.milliways.fr signature.asc Description: OpenPGP digital signature
Re: Google Summer of Code 2009: Debian's Shortlist
=== Debian's Shortlist: === = - Aptitude Package Management History Tracking /var/log/dpkg.log? harry signature.asc Description: PGP signature
Re: Google Summer of Code 2009: Debian's Shortlist
Harald Braumann a écrit : === Debian's Shortlist: === = - Aptitude Package Management History Tracking /var/log/dpkg.log? harry The basis of the proposal is here: http://lists.alioth.debian.org/pipermail/aptitude-devel/2008-December/001071.html It's much more than dpkg.log Cheers Arthur -- Obey Arthur Liu http://www.milliways.fr signature.asc Description: OpenPGP digital signature
