Location: Xalapa, Mexico
Spoken languages: Spanish, English, French
Written languages: Spanish, English
GPG Signature: 0x46D9CE5A
Table of Contents
- Notes on this page
- Mission in Debian
- Proposed changes
- Current work
- About Ubuntu
- External Links
Notes on this page
This page will only talk about my Debian-related opinions, work, etc. For other kind of information (e.g. my other non-Debian projects) check the links at the bottom of this page.
Mission in Debian
Debian is my primary OS used in desktop and server environments. Here are some of my personal goals in my involvement with Debian.
There are tons of useful, and useless, software out there; and it happens that some of them are commonly used by a high amount of people but they are not available in Debian.
I would like to see more useful software available in Debian. This goal can only be accomplished by getting more people involved in packages maintenance.
QA is not only about fixing bugs. QA is about all. I want to keep and even help increase the Quality of Debian in many ways (see below to see what I'm currently working on).
Very personal way to describe QA: "QA is the difference between Debian and Ubuntu" (see About Ubuntu below)
Debian as a desktop OS
As simple as this: Debian is a good OS for desktops.
All is needed is make it more user friendly and provide easier ways to setup "standard" environments (some good job has been done with the new graphical installer, and other changes).
License: in debian/control
Note: I'm no longer supporting this proposition (now looking how to implement license tags, using debtag of course).
One of the common problems I've found while packaging software for Debian is the licenses which software is released under.
This proposition rather than replacing debian/copyright is a complement that would help end users and new developers to easily check the license of a package and thus making them more license aware.
The proposition is to add a License: entry in the debian/control files, which would indicate the license of the given package.
Since some software have all of their files released under the same license it would also be possible to include a single License: entry for the whole source package.
Why should the License: entry be added? As I previously said, I've encountered many license problems (mainly conflicts) during my very short period of time as a Debian maintainer. This entry would permit software to detect conflicts between packages (because of licenses).
Why is it different from debian/copyright? debian/copyright provides a lot of very useful information but it is not possible (or easy job) for an application to use that information. An other difference is that the License: entry would only cover the license typo of a given package, debian/copyright covers everything (licenses, copyright information, etc).
How would an entry look like? Following the same format as for conflicts, depends, etc:
License: GPL (>= 2), LGPL (>= 2.1)
The above example would mean that the package is released under the GPL2 and LGPL2.1 licenses. The > sign is used because according to the licenses a newer version of the license can be used.
What about exceptions? Based on a real life example, this is how ffmpeg-php's License entry would look like:
License: GPL (>= 2) | php (PHP = 3.01)
Even tough this is a more complex situation, it can be read like this:
ffmpeg-php is licensed under GPL2 (but newer versions might be used) with an exception for the php source package which is released under the PHP license version 3.01.
What about providing a semi-stable distribution where packages older than one month are pulled from testing.
This semi-stable distribution could be very useful for home users, providing more stability than testing but more recent versions than stable.
New extensions manager for PHP
See the wiki's PHP Page
Encouraging the usage of tags when reporting bugs
Because of the activities I've been doing lately I came to the necessity to encourage people to use tags on their reports. There are plenty of tags which could be used to make maintainers and non-maintainers life slightly easier.
Probably making reportbug and similar tools ask what kind of wishlist report the user wants to submit would be better.
This could help for example standardise the usage of
User: firstname.lastname@example.org Usertags: new-upstream
and such to make it easier to detect when a given kind of report has already been filed against an specific package.
This is a brief list of stuff I'm working on.
New extensions manager for PHP
See above for more information
DEHS-based bug reporting
I've started filing bug reports against packages whose debian/watch file fail to report upstream's version.
I've plans to extend this bug reporting to:
- New upstream versions available (Severity: wishlist)
- Watch Wizard-generated debian/watch file available (Severity: wishlist)
I believe keeping packages up to date may reduce (and sometimes increase, but that's life) the number of bugs on them. Also, people want recent package versions.
The old ones may be rock stable, but newer versions will never become rock stable if they aren't tested
All this job has to be done step by step, that's why I began by reporting bogus/outdated watch files.
Some benefits from reporting can already be seen: many packages have been updated to the latest upstream version. These short-term results demonstrate what could happen if a mass bug filing about a new upstream version available is done.
Of course this last needs to be done carefully to prevent mass duplicated bug reports.
The second step would be to fill reports based on the Watch Wizard-generated watch files.
This would increase the number of packages upstream versions can be checked for. And probably would have a similar short-term effect such as the one caused by the first MBF.
And the third step would be to fill reports so maintainers package a new upstream version.
Of course this bug filing is planned to be long-term, but the first run of the scripts will usually cause a MBF (785 for the first step).
I know some people don't think bug filing is a solution, either because not every maintainer has a lot of time in their hands to keep their packages constantly up to date, or purely and simply because a new upstream version is not a bug but a feature.
Everybody has their own point of view, and I fully accept that. I don't want everybody to agree or share the my point of view. But what I want is maintainers becoming aware that by uploading a package to the archive they need to maintain it, and maintaining a package also means keeping it up to date because people rely on that person to have the latest upstream package available (but in no way I mean they should have the latest upstream version packaged within a week or two. A delay of one month is considerably ok).
Otherwise they should better orphan the package and let someone take care of it or better don't upload it at all.
I'm aware that currently as a student I have more free time than what I could have in the future. But by packaging and asking to have my package uploaded I'm fully aware of my responsibilities now and in the future.
freshmeat.php: watch files helper
See my announcement thread at debian-qa for more information.
dash as /bin/sh release goal
dash is a faster /bin/sh replacement so I would like to see it become the default sh in lenny.
Because of that reason I've done several archive wide checks with checkbashisms (from the 'devscripts' package) and filled reports accordingly.
While working on this release goal I've confirmed, once again, the QA level of Ubuntu: as most people know dash is the default sh in Ubuntu; they made this change a while ago just because of performance of the system, without doing the necessary previous work which consists of checking for bashisms in shipped scripts, in the build process, everywhere!
A distribution of the kind of Debian can't simply make this change, people rely on Debian; and bashisms whether we like them or not, are bugs. Sometimes they cause missbehaviours or even prevent the scripts from working.
This section is in Spanish for kind-of obvious reasons :).
Empaquetando extensiones PECL de PHP
En esta plática se planteará tanto el empaquetamiento de extensiones de PECL, como los efectos secundarios provocados por el uso de conf.d/ para almacenar las configuraciones de dichas extensiones.
Los interesados deberán de contar con:
- Un poco de experiencia creando paquetes para Debian, y conocimieto del funcionamiento de make (no se necesita mucho tampoco)
- Algunos paquetes como: php5-dev, devscripts, build-essential, debhelper, dh-make-php, wget
- Un editor de textos
- Idea de que extensión de pecl.php.net desean empaquetar
Recomendaciones (pero no obligatorio):
- Contar con pbuilder o algun sistema parecido (si se cuenta con uno se deberá saber usarlo, ya que no se va a explicar nada de eso).
- Tener ganas de después subir y mantener el paquete en Debian
Introducción a pbuilder y piuparts
En esta plática se planteará el uso de pbuilder como herramienta para compilar paquetes (en lugar del uso directo de dpkg-buildpackage, apt-get -b source, debuild y similares) así como el uso de piuparts para verificar la instalación, desinstalación así como la actualización de cualquier version previa a la nueva.
Esto con el fin de dar a conocer una serie de herramientas básicas para la creación y mantenimiento de paquetes.
Notas sobre piuparts: Debido al tiempo que se tarda en descargar los paquetes al momento de realizar las pruebas, se tratará el tema principalmente de manera teórica. A excepción de el hecho de que se mostrarán los resultados de algunas pruebas, realizadas con anterioridad, para así explicar de una manera más clara el uso de esta herramienta.
Los interesados deberán de contar con:
- Un poco de experiencia creando paquetes para Debian (métodos para compilar los paquetes así como conocer su funcionamiento básico).
- Los siguientes paquetes: devscripts, build-essential, debhelper, pbuilder, piuparts, entre otros
- El .dsc, .orig.tar.gz y .diff.gz de un paquete que deseen compilar y probar
- Usar testing o unstable (o su equivalente en Ubuntu respecto a las versiones de los paquetes)
- El conocimiento de que las preguntas se harán en #debian-mentors-es
Recomendaciones (pero no obligatorio):
- Tener las dependencias (depends y build-depends) del paquete a compilar ya en el cache de apt
- Tener ganas de asistir a la siguiente plática sobre el uso de apt-cacher
- Tener un mirror cercano o inclusive local (ya que piuparts se tomará su tiempo para descargar los paquetes al momento de realizar las pruebas).
My opinion about Ubuntu:
Ubuntu as a project (a.k.a. pros)
I find some of the ideas (whether they were intentional or not) behind Ubuntu as very good: release soon, include more, easy to use, not afraid of changing.
Release soon: One of the main "problems" I find with Debian is its always long-waited new stable release.
Include more: Lots of new packages are available thanks to the universe (correct me if mistaken) repository.
Easier to use: Many things are more home users friendly than it's counterpart at Debian.
Not afraid of changing: Ubuntu has caused some changes to be made in the Linux world and in the Debian world; mainly because they just make the changes.
Ubuntu as what it currently is (a.k.a. cons)
Release soon: it is well known that there is no easy way to upgrade between releases, making the whole release soon thing more a deception than a pro. Update: it seems like I'm one of the very few people who have *faced* these problems.
Include more: as I said, the universe repository idea is cool; but the problem is that the QA level, lack of maintenance on some packages, and bad packaging (which may or may not affect the final .deb package) makes me think more than twice before installing a package from universe.
About this all I have to say is: if the packages are good, they should be in Debian and thus in Ubuntu.
Easier to use: As stated above: it is "home users friendly" which sometimes happen not to be the best for non-home users (this is my main critisism for GNOME: its friendliness makes it hard to use for people who need more customisation).
Not afraid of changing: Changing things may "reduce" the stability of a well-known system. Even tough it is not bad at all to make big changes time by time
Ubuntu and QA
- No easy way to upgrade between releases (they say it is, but tests doesn't confirm that)
Packages are taken from Debian unstable (isn't the unstable name more than enough for this??)
- Changes usually made usually without much care about bad impacts