Nueva disposición de metapaquetes en KDE 4

Burda traducción del mail de Ana Guerrero a la lista Debian-KDE:

El equipo Debian-Qt-KDE ha transicionado los metapaquetes de KDE a KDE 4.

Todos los paquetes kde4-* que se utilizaron en experimental y, por un breve período de tiempo, en inestable, han desaparecido.

La disposición actual es ahora:

kde-minimal: exactamente igual que su predecesor kde4-minimal. Como su nombre lo indica, instala un ambiente mínimo de KDE.

kde-full: originalmente llamado kde4, instala el ambiente completo de KDE 4, es decir, todos los módulos oficiales.

kde-standard: éste es un paquete nuevo, actualmente igual a kde-minimal. El propósito de éste paquete es instalar lo que un usuario al azar esperaría de un ambiente de escritorio. Por el momento éste metapaquete sólo contendrá lo básico, hasta que nos pongamos de acuerdo en qué vamos a proveer aquí.

El método recomendado de instalación es usar kde-minimal y luego instalar las aplicaciones que se deseen.

kde-standard va a ser para usuarios novatos, que quieren un poco de todo al principio, cuando no saben que aplicaciones se encuentran disponibles. Con el tiempo, irán aprendiendo que paquetes van a querer/necesitar y sencillamente los instalarán.

Se encuentran todos invitados a discutir acerca de cómo deberían ser los metapaquetes, en la lista Debian-KDE. Algunos incluso van a llenar wishlist bugs (que serán marcados como wontfix). Por lo tanto, traten de entender que el set "ideal" de paquetes varía de persona en persona, y por eso intentamos que se mantengan simples y útiles.

Debian's NEW queue: a proposal

In a previous post, I ranted about Debian's NEW queue. In that post I said I din't had an idea on how to fix it. Now I do. Please consider this something like a "non-official Debian draft RFC".

The queue's restrictions:

• Debian can not guarantee that packages uploaded to the queue are fitted for the project, so they must not be publicy available.
• It must be a ftp-master the one who does the final check and decide wether to let the package in the repos or not.
  

The proposal basics:

• Let the packages be peer-pre-reviewed.
• Allow access to the packages only to specific people.
• The queue must be per-day-FIFO (more on this later), with the exception of packages that fixes RC bugs.

Posible implementation:

Allow both DDs and contributors to help (and thus, permission for accesing the packages in the queue). DDs are easy, contributors must fill some requirements:

• Have a PGP key signed at least by two DDs. The same requirement for becoming a DD.
• Ask permision ¿on some public list? to do the job. The contributor key must be added to a list of allowed keys.

Now for each package, a reviewer (now considering both DDs or contributors) must review the package (of course) and send a PGP signed mail with the acceptance of the package or notes on why it does fail, much in the way we already do with the BTS's control e-mail address. In case of comments, the uploader will receive a copy and may decide to upload a new version of the package, going to the bottom of the queue.

Why the need of the PGP signature? In this way we restrict the access to the packages in the queue to people that has been allowed to do that, and the sign in the e-mail will check that this person can review packages.

When a contributor accepts a package, it gives (for example) a point for that package. When a DD accepts the package, it gives (again as an example) two points to the package.

Now to the ftp-master game: when the ftp-master reviews the queue, it must take only packages from the latest day in the queue, not being able to review other package of a nearer day until the packages of the latest days are all reviewed (thus the per-day FIFO queue). Packages fixing RC bugs are an exception to this rule (thus we may consider two queues with priorities).
The puntuation given in the points below will help the ftp-master in reviewing the package: packages with more points were more peer-reviewed, packages with less points will need less attention. Comments will help to pin-point problems in a fastest way.

Of course, one may argue that the points are useless, but I think in this way people are encouraged to do revisions of the packages.

This being a "non-official Debian draft RFC", I wait for your comments :-)

Update (20090425 11:38 GMT-3): Ana told me that very similar things have been already proposed by several people before, and it seems that the FIFO idea just doesn't work. I must admit I was waiting someone to come up with this, but I have ranted and not proposed a solution, so at least with this I have tried :-)

Debian's shame

Got your attention? Good. First of all, the disclaimers: I am not a Debian Developer (DD), just a simple contributor. I may not be accurate in the following, and maybe I will create a flame out of this. Sometimes the land needs to be put on fire to produce better later. You have been warned.

I am not going to talk about a software flaw in Debian. Debian handles this questions very clearly and openly. No. What I want to rant about today is the NEW queue. Everyone who gets involved in Debian nows about this queue and why is it needed. New programs (and packages that were in the repos but change to provide new binaries) have to go to this queue first, so as to be checked that they can really be in Debian's repo. So far, so good.

So, what's the problem with the queue? The time it takes a package to go trough it. We all now that a QA check needs to be done and this takes time, but ¿almost two months just for that? In my [¿NS?]HPOV, that's a shame.

I'm ranting about this, but do I propose a better scheme? No, because there have been other propositions from people who have things much more clearer: DDs.

Guys, I really understand there is a lot of effort in the project, but this queue needs a change. Comments are most welcomed :-)

La vibración y los discos rígidos

Russell Coker (via Planet Debian) escribe en su blog sobre los efectos de las vibraciones y el rendimiento de los discos SATA.

Siempre dije que es mejor tener el gabinete en un lugar con las mínimas vibraciones posibles. Si bien en éste caso pareciera ser un problema de armónicas entre los ventiladores y el disco, las vibraciones no son buenas.

Mi gabinete está puesto en una repisa amurada a la pared, sin ningún otro artefacto en ella. Puse la repisa a la misma altura del escritorio, y conservo una distancia de aproximadamente 2 cm entre ellos.

Luna y el escritorio

¿Porqué la mismo nivel? Visualmente me resulta una "continuación del escritorio". Ni hablar que podría reducir la probabilidad de golpes si estuviese mas alta la repisa, pero lo mas importante es reducir una de las principales fuentes de vibración: la que uno mismo provoca sobre el escritorio.

Como ya deberán estar intuyendo, no soy para nada amigo de dejar los gabinetes sobre el mismo escritorio de trabajo, aún aunque el gabinete se encuentre en su parte inferior.

Otro "detalle" que he notado, aunque muy empíricamente, es que los CDs grabados desde que tengo la repisa suelen ser mas legibles por lectoras agotadas que muchos de los que hice cuando aún conservaba el gabinete sobre el escritorio.

Por supuesto, siempre quedan vibraciones, en especial las de baja frecuencia (vivo a 100 metros de las vías del tren), pero bueno, se hace lo que se puede :-)

Nota: el logo de Debian me lo dió Luciano Bello durante la DebConf 8. Es mas o menos como un tesoro por partida doble :-)

firmware-linux

¿Actualizaron el kernel en Debian al 2.6.26-2 y la placa de red les dejó de andar? ¿O la placa de video? ¿O ambas?

Los firmwares de muchos dispositivos ahora se distribuyen en un paquete aparte: firmware-linux. Basta con instalarlo (y posiblemente reiniciar la máquina) para que las cosas vuelvan a ser como antes.

El efecto cover switch de KDE 4

Hace rato que uso KDE 4. Y hace rato que quería tener andando el efecto cover switch. Pero con mi placa de video, parecía no haber caso:

01:05.0 VGA compatible controller: ATI Technologies Inc RS690 [Radeon X1200 Series]

El efecto cover switch en KDE 4

Ayer actualicé mi Debian Sid y noté la actualización del módulo radeon. Hoy se me dió por activar los efectos y... ¡voilá! Tengo el efecto andando. También entendí un pequeño gran detalle: la sincronización que tiene que haber entre dos opciones de configuración.

Veamos la primer pantalla:



Noten el menú "Efecto para el cambio de ventana". En éste momento está seleccionado "Selección de ventana en modo carátula", el cover switch. Resulta ser que hay varios efectos que proveen funcionalidades similares, como podemos ver en la siguiente imagen:

Como podrán deducir, en el primer menú necesitamos elegir cuál de los efectos vamos a usar. Ésta selección se cambia automáticamente si elegimos un efecto en el listado, pero al elegir varios puede ser necesario ser "mas fino".

Ahora me queda jugar con las opciones de aceleración a ver cuál me es mas conveniente :-)

KDE 4 (4.2.2) en Debian unstable (Sid)

A partir de hoy disponemos de KDE 4 (4.2.2) en Debian Sid (unstable/inestable).

¡Que lo disfruten!