¿Cómo funciona la Junta de Revisión de Solicitudes?

De acuerdo con https://wiki.ubuntu.com/AppReviews, el proceso de revisión de aplicaciones es bueno tanto para los desarrolladores de software como para los empaquetadores de Ubuntu. El punto parece ser que los desarrolladores ascendentes tienen la ventaja de ingresar sus aplicaciones en el Centro de software antes y de manera más fácil, mientras ayudan a los administradores de paquetes de Ubuntu preparando su aplicación para el empaquetado.

Esto parece ser una gran oferta. Las instrucciones en wiki indican que un desarrollador cumple algunos de los pasos que se enumeran allí, incluida la carga de la aplicación en un PPA, y solicita una revisión, y después de un tiempo se revisa, y se acepta e incluye en los repositorios de Ubuntu, o no se acepta en absoluto.

Aunque esto parece una forma simple y justa de agregar rápidamente una aplicación al Centro de software, creo que me falta algo. Me he dado cuenta de que, si bien hay algunas solicitudes pendientes , no hay (o apenas hay) actividad allí. Todo parece estar congelado hace unos 5-6 meses, y huele un poco abandonado.

¿Entendí algo malo y todo está bien (tal vez, por ejemplo, ¿se están revisando solo en la UDS?) O algo cambió? ¿Podría alguien explicarme claramente, cómo funciona exactamente este proceso de revisiones (e inclusión en repositorios)?

Situación actual

El ARB fue un tema de sesión (martes 6 de septiembre) en la reciente Semana de Desarrolladores de Aplicaciones de Ubuntu (5 al 9 de septiembre).

Resumiendo el aula de IRC (transcrita a medida que se desarrolla la lección, de ahí la brevedad y que refleja el orden de la lección):

1. En el futuro, al igual que las aplicaciones de pago, las aplicaciones gratuitas / gratuitas se enviarán a través del portal MyApps (ver el plano a continuación)
2. El ARB es un grupo de 4 miembros de la comunidad responsable de permitir pequeñas aplicaciones independientes en una distribución estable (es decir, se ha lanzado)
3. Board ofrece asistencia para el empaquetado y garantiza que las aplicaciones cumplan con las reglas estándar de empaquetado de ubuntu.
4. Dos aplicaciones han pasado por el proceso: 'Noticias' y 'Sentencia suspendida', ambas puestas a disposición de Maverick (10.10)
5. Confirmó que Launchpad se descartará a favor del portal MyApps.
6. Formas de obtener aplicaciones gratuitas / libres en ubuntu : a través de debian y sincronizar con ubuntu antes de congelar funciones, a través de un puerto o a través del ARB
7. Formas de recibir pagos por aplicaciones en ubuntu: aplicaciones asociadas de Canonical (caso por caso) o mediante aplicaciones de compra a través del Centro de software
8. Si se envía a través de ARB, usted es el responsable del mantenimiento y es responsable de enviar cada nueva versión de Ubuntu. De ahí la preferencia por los paquetes ascendentes, ya que se sincronizan automáticamente.
9. Las aplicaciones aceptadas por ARB se agregan al extras.ubuntu.comrepositorio
10. Si hay un error crítico o un problema de seguridad en un paquete ARB, un miembro de la junta intentará solucionarlo con el mayor esfuerzo posible; luego, póngase en contacto con el responsable del mantenimiento. Cuando el responsable no responde, la aplicación se eliminará y se enviará un paquete vacío.
11. Los miembros de ARB reconocen el proceso de revisión de longitud. Busca usar Arkosepara contener aplicaciones: similar a la aplicación de Android con una lista de acciones que una aplicación puede realizar. Debería permitir una revisión más rápida sin tener que hacer una revisión completa del código (esta es la razón clave del retraso de longitud actual). También es la razón por la que no puede aceptar aplicaciones complejas o aplicaciones escritas en ciertos idiomas
12. También busca producir un script de debhelper para empaquetar automáticamente una aplicación para cumplir con las reglas ARB.
13. A largo plazo: envío a través de MyApps como tarball del código fuente con una receta de compilación. Esto generará un perfil de Arkose o Apparmor, etc. El proceso ARB debe revisarse en horas (en lugar de hacerlo ahora) antes de pasar al Centro de software.

Plano ARB

El plan Oneiric ARB se planteó en mayo de este año y está dirigido a Oneiric.

La etiqueta de revisión es "Queremos socializar cómo las personas pueden obtener sus aplicaciones en Ubuntu, y queremos revisar qué tan bien está funcionando el ARB.

• ¿Qué cosas funcionan bien?
• ¿Cuáles son las áreas que necesitan mejoras? "

Se han realizado algunos progresos en el logro de los objetivos del proyecto:

• Nueva lista de correo de revisión de aplicaciones (app-review-board@lists.ubuntu.com)
• lista de verificación de pasos para cargar aplicaciones en el repositorio de extras en vivo
• Progreso para hablar con las partes interesadas sobre cómo simplificar el proceso de fusión e incorporación de cambios
• Preparación y artículo para publicar en Ubuntu Planet
• Nueva página web beta para que los desarrolladores guíen a través del proceso de envío (aunque actualmente para desarrolladores comerciales)

Como indican las notas en el plano impreso, los propios desarrolladores de Canonical necesitan "motivar" para que el proceso ARB funcione. Se habla de reclutar a alguien principalmente para hacer avanzar el proceso.

Periodo de tiempo

Entonces, para responder la pregunta: el ARB está trabajando para desarrolladores comerciales (solo), con planes para que el ARB esté funcionando completamente dentro de los plazos de Oneiric.

Sin embargo, podría especular, dada la cantidad de elementos pendientes en el plan, tal vez 12.04 sería una apuesta más segura.

En mayo, hubo una sesión de evaluación y evaluación de ARB destinada a mejorar la forma en que funciona ARB: http://summit.ubuntu.com/uds-o/meeting/16441/community-o-app-review-board-review-and -evaluación/

De estas notas, parece que no está abandonado, sin embargo, en realidad no funciona bien a partir de ahora.