Differences between revisions 6 and 8 (spanning 2 versions)
Revision 6 as of 2007-11-20 20:50:43
Size: 13675
Comment: updated, reorganised, etc
Revision 8 as of 2007-12-01 22:04:32
Size: 13868
Comment: making the text easier to read
Deletions are marked like this. Additions are marked like this.
Line 106: Line 106:
Line 107: Line 108:
{{{
Line 109: Line 111:
}}}
Line 132: Line 135:
Line 135: Line 139:
Line 136: Line 141:
These short-term results demonstrate what could happen if a massive bug filing about a new upstream version available is done.
Of course this last needs to be done carefully to prevent massive duplicate bug reports.
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.
Line 140: Line 146:
This would increase the number of packages upstream versions can be checked for. And probably have a similar short-term effect such as the one caused by the first MBF.
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.
Line 147: Line 154:
Line 149: Line 157:
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.

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.
Line 158: Line 167:

=== freshmeat.php: watch files helper ===

See my [http://lists.debian.org/debian-qa/2007/11/msg00033.html announcement thread] at debian-qa for more information.

Quick info

Status at Debian: [http://qa.debian.org/developer.php?login=Raphael+Geissert maintainer]

Location: Xalapa, Mexico

Contact: atomo64@gmail.com

Spoken languages: Spanish, English, French

Written languages: Spanish, English

GPG Signature: 0x46D9CE5A

Table of Contents ?TableOfContents()

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.

Packages maintenance

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

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).

Proposed 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.

SemiStable

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 [http://wiki.debian.org/PHP#head-3a3ea90a961ce57ab37e4e4c832448d58e2cf16d 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: debian-qa@lists.debian.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.

Current work

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 [http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=atomo64@gmail.com;tag=dehs-no-upstream bug reports] against packages whose debian/watch file fail to report upstream's version.

Future plans

I've plans to extend this bug reporting to:

  • New upstream versions available (Severity: wishlist)
  • Watch Wizard-generated debian/watch file available (Severity: wishlist)

Why?

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.

DeBaBaReTools

See my [http://my.opera.com/atomo64/blog/2007/10/19/debabaretools-the-de-what introductory blog post] for more information. Latest news always posted on my blog with the [http://my.opera.com/atomo64/blog/index.dml/tag/DeBaBaReTools ?DeBaBaReTools tag].

freshmeat.php: watch files helper

See my [http://lists.debian.org/debian-qa/2007/11/msg00033.html announcement thread] at debian-qa for more information.

DebianSpanish/Devel/IRCTalks

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).

About Ubuntu

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

Criticisms:

  • 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??)