You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
52 lines
2.3 KiB
52 lines
2.3 KiB
|
|
La Guía de Parches de ROCK Linux
|
|
================================
|
|
|
|
Para lograr que la aplicación de los parches sea lo más eficiente posible,
|
|
el envío de los parches debería de ser en el formato descrito aquí. Yo
|
|
(y alguno de los desarrolladores de subdistribuciones) rechazaremos los
|
|
parches si no están conforme a este documento.
|
|
|
|
Por favor, pon la cadena [PATCH] al inicio del campo Asunto del correo.
|
|
Podría no ser visto si no forma parte de los primeros carácteres, ya que
|
|
algunos clientes de correo sólo muestran el inicio del campo Asunto en la
|
|
lista de correos.
|
|
|
|
0. NO ENVÍES PARCHES NO TESTEADOS ANTES, SIN DEJAR CLARO QUE AÚN NO HAN
|
|
SIDO PROBADOS, Y NO ESPERES QUE PARCHES SIN TESTEAR SEAN APLICADOS. En
|
|
caso de actualizaciones de paquetes, etc. es suficiente con asegurarse
|
|
que el paquete aún se compila correctamente con una configuración más
|
|
o menos genérica.
|
|
|
|
1. Los parches deben estar en un formato unificado. Yo prefiero diffs
|
|
unificados. Debería ser posible aplicar el parche con el comando 'patch
|
|
-p1 < patchfile' en el directorio base.
|
|
|
|
2. El parche no debe contener nigún fichero que sea generado de forma
|
|
automática por ./scripts/Puzzle.
|
|
|
|
El script "./script/Create-Diff <dir_antiguo> <dir_nuevo>" puede ser usado
|
|
para crear facilmente parches conformes al punto 1 y 2.
|
|
|
|
3. El parche debe ser contra uno de los últimos snapshots del desarrollo.
|
|
|
|
4. Un parche debe arreglar sólo un tema. Si pretendes arreglar varias cosas
|
|
(independientes), envía varios parches.
|
|
|
|
5. Si un parche no es autodescriptivo en pocas líneas, añade un pequeño
|
|
comentario al principio del fichero del parche.
|
|
|
|
6. Si no recives ningún tipo de respuesta y no ves el parche en los snapshots
|
|
después de una semana, reenvía el parche al desarrollador del paquete.
|
|
|
|
7. No empaquetes los parches en ficheros tar. Los hace mucho más pesado para
|
|
abrirlos y leerlos en un cliente de correo. Comprime un parche sólo si es
|
|
reálmente grande.
|
|
|
|
8. Informa al responsable del mantenimiento del paquete cuandO empiezas a
|
|
trabajar en un problema, para asegurar que estás duplicando trabajo.
|
|
|
|
9. No me envíes los ficheros que hayas añadido o modificado. Envíame un parche
|
|
contra los fuentes de ROCK Linux (como se describe atrás).
|
|
|
|
10.¡NO ENVÍES FICHEROS TAR QUE REEMPLAZCAN LOS FICHEROS QUE HAS MODIFICADO!
|