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

Table of Contents ?TableOfContents()

Mission in Debian

Debian is my primary OS used as desktop and server.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 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.

I want to keep and even help increase the QA level of Debian.

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 it needs is to make it more user friendly and provide easier ways to setup "standard" environments (some good job has been done with the new graphical installer).

About Ubuntu

My opinion about Ubuntu:

Ubuntu as a project (pros)

I find some of the ideas (whether they were intentional or not) behind Ubuntu as very good: release soon, include more, easier 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 is currently is (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.

Include more: as I said, the universe 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 not only 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: "home users friendly" which sometimes happen not to be the best for non-home users (this is my main criticise 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:

Proposed changes

License: in debian/control

Note: I'm no longer supporting this proposition (now looking how to implement licenses tags, using debtag).

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 of packages than stable.

New extensions manager for PHP

See the wiki's [http://wiki.debian.org/PHP#head-3a3ea90a961ce57ab37e4e4c832448d58e2cf16d PHP Page]

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;usertags=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:

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 ;-) [More/better reasons coming soon, no time to write a lot right now]

DebianSpanish/Devel/IRCTalks

This section is in Spanish for 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:

Recomendaciones (pero no obligatorio):