Ideas: Google Summer of Code 2011

Estado:

Resumen de idea: https://launchpad.net/wubi es una gran herramienta que permite a uno instala Linux desde una ventana de SO. Sería bueno tener algo como esto también para Fedora.

Contactos:

Mentor(es):

Notas:

Estado: Propuesto

Resumen de Idea: El sistema utilizaría un perfil de red apropiado (p. ej. opciones de proxy) por cada lugar de red.

Actualmente, GNOME tiene un concepto de lugares de red en su ventana de configuración de Network Proxy. Sin embargo, el usuario seleccionaría el lugar apropiado en cuanto se mueva entre las redes. Esta idea es acerca de proporcionar una integración entre NetworkManager y los entornos de Escritorio tales que un usuario pueda crear perfiles de red para cada localización de red proporcionando la configuración adecuada, como la configuración de proxy, que es la principal propuesta aquí. NetworkManager puede tener un concepto de «Lugar de red»: para redes inalámbricas, usualmente el nombre de la red (ESSID) suele ser suficiente. Para conexiones por cable, los servidores DHCP pueden proporcionar, y suelen hacerlo, el nombre de dominio de la red, que puede usarse como nombre del lugar. Es conveniente que el usuario pueda asociar cada lugar de red con un perfil de configuración de red que se usará automáticamente al conectarse a esa red. De esta manera, al conectarse a una red, se activa el perfil de configuración de red correspondiente automáticamente.

ContactOs: Hedayat Vatankhah

Mentor(es):

Estado: Propuesto

Resumen de idea: Añade algunos del desaparecidos 3d APIs para al menos uno de los tipos de carta importantes, considerablemente ayudando fuera del asediado Radeon y Nvidia esfuerzos de ingeniería inversa. Hay bastante actualmente (F14) perdiendo que la mayoría de 3d los juegos no funcionan correctamente, muchos del underpinnings de FireFox 4 aceleración es blacklisted debajo Linux, y muchos otro visuales y otros componentes no pueden hacer uso correcto del gpu(s) debajo Linux. El progreso es abismal para muchas razones.

Contactos:

Mentor(es):

Notas: Requiere una buena integración con los equipos Radeon y nVidia existentes y sus suites de pruebas

Estado: Propuesto

Resumen de idea: SPICE es un protocolo de interacción con escritorios virtuales que sería un sustituto ideal para VNC y las implementaciones actuales de LTSP basadas en X. Usar SPICE mejoraría la experiencia del usuario al implementar algunas funciones faltantes, como el sonido en VNC, y hacer que LTSP sea más eficiente que usar X sin formato. Un protocolo común para todos los tipos de pantallas remotas también simplificaría la configuración del cliente. Puede encontrar más información sobre SPICE aquí:

http://www.spicespace.org/

Contactos:

Mentor(es):

Notas:

Estado: Propuesto

Resumen de la idea: Existe un problema importante con el empaquetado RPM de Erlang. Las dependencias entre paquetes de Erlang aún deben calcularse manualmente. Se intentó crear un listado de proveedores y requisitos automáticamente durante la fase de compilación, pero no se completó. Otra tarea interesante es integrar estrechamente la función esencial de Erlang/OTP para las actualizaciones de aplicaciones en vivo con el proceso de actualización RPM, lo que permite actualizaciones fluidas de las aplicaciones Erlang en ejecución.

Contacto: Peter Lemenkov

Mentor: Peter Lemenkov

Notas: Se requieren conocimientos básicos del proceso de creación de RPM y del procedimiento de instalación. También se requieren conocimientos básicos de Erlang.

Estado: Propuesto

Resumen de la idea: Varias aplicaciones de la Estructura de Fedora están escritas en TurboGears 1.0 y, para mayor durabilidad, es necesario migrarlas a TG2. Estas incluyen bodhi, mirrormanager, packagedb, election, fas y smolt.

Contactos: Matt Domsch, Toshio Kuratomi

Mentor: mdomsch

Estado: Propuesto

Sumario de idea: MirrorManager proporciona las listas de réplicas a todos los sistemas Fedora. Además de la adaptación a TG2 (vea arriba), se agradecerían varias mejoras:

Contacto: Matt Domsch

Mentor: mdomsch

Estado: Propuesto

Resumen de la idea: La idea es crear un sitio web que permita mostrar eventos, divididos por región, lista de asistentes, temas tratados y otros puntos. Para referencia, consulte Ubuntu Loco Events.

Hoja de ruta (Trabajo en progreso. Las tareas están definidas, pero aún no las fechas)

Contactos:

Mentor: Nushio desarrolla webapps como trabajo diario y no me importaría convertirlo en un trabajo de verano también.

Notas: giallu el sitio de Ubuntu es una aplicación de Django, el código está disponible como GPLv3 http://bazaar.launchpad.net/~loco-directory-dev/loco-directory Si no requieren la asignación de derechos de autor, consideraría usarlo

Estado: Propuesto

Resumen de la idea: cuando los usuarios necesitan anular un buildroot, pueden gestionarlo todo ellos mismos.

Para esto veo 2 partes: integración de cli en fedpkg, es decir, "anulación de fedpkg" y un servidor con el cual hablar, rastrear las anulaciones y hacer el etiquetado y desetiquetado real - flujo de trabajo posible: permitir al desarrollador especificar una vida para la anulación, con un valor predeterminado de 24 horas: el servidor luego haría la etiqueta en koji y al final de su vida la desetiquetaría. Podría ver tener una aplicación web para ver las anulaciones actuales, permitir solicitudes, extensiones, etc

Contactos: Dennis Gilmore

Mentor: Dennis Gilmore

Estado: Propuesto

Resumen de idea: mw es un programa de línea de comandos que pretende ser un sistema de control de versiones. Eventualmente debería ayudar a las personas que están locas por las consolas (como yo) para editar wikis basados en MediaWiki sin tener que gritarle a su navegador web.

Contacto: Ian Weller

Mentor: Ian Weller

Notas: Aquí hay algunas ideas para estudiantes: reflexiones de User:Ianweller/mw

Estado: Propuesto

Resumen de la idea: Finalizar e implementar el concepto de repositorios personales iniciado por http://repos.fedorapeople.org

Copr (Cool Other Package Repo) es un proyecto de Fedora que facilita la creación y gestión de repositorios de paquetes de terceros. La instancia que se instala en la infraestructura de Fedora permite a los mantenedores de Fedora crear repositorios de paquetes para compilar y compartir con otros.

Como usuario y embajador de Fedora, me preguntan mucho sobre esta característica de Fedora.

Contactos:

Mentor(es):

Resumen de la idea: Generar casos de prueba de difuso (fuzzing) a partir del comando "make test" existente, cuya eficacia generalmente depende del esfuerzo invertido por el responsable del paquete. Ampliar el rango de casos de prueba de forma genérica contribuye a mejorar la calidad y la seguridad de las pruebas de software. La técnica clave de implementación consiste en proporcionar dispositivos de fuzzing simulados e instrumentación transparente en proceso (bucles de fuzzing), lo que mejorará el tiempo de respuesta y la tasa de detección de errores. La integración transparente en herramientas de compilación (como las macros rpm-build) facilita el acceso a desarrolladores y responsables de mantenimiento.

Componentes clave:

-Dispositivos de fuzzing: Nos referimos a dispositivos de espacio de usuario que manipulan datos originales proporcionándolos basándose en una estrategia de fuzzing determinada; la estrategia elegida depende de la naturaleza del tipo de archivo, implementada mediante plugins (para empezar, proporcionamos un origen de plugins completa para tipos de imagen, gif, png, multimedia, midi).

-Proceso de control de calidad (QA) de paquetes: Creemos que una integración prototípica en rpm-build (macro, omisión previa de ciertos resultados) ayudará a los desarrolladores y mantenedores de paquetes (de Fedora) a beneficiarse de forma transparente de estas funcionalidades durante la compilación de paquetes.

Objetivo: Se espera que todas las variantes POSIX puedan beneficiarse de la integración de algoritmos de fuzzing en dispositivos, sin embargo, debido a la compatibilidad con la macro rpm-build, esperamos que las distribuciones basadas en rpm obtengan el mayor beneficio.

Contactos: Marc Schoenefeld, mschoene@redhat.com

Mentor: Marc Schoenefeld , mschoene@redhat.com

Estado: Propuesto

Resumen de la idea: Actualmente, al compilar localmente con Maven, es necesario especificar manualmente las dependencias de compilación en todos los archivos spec. Las bibliotecas Java y los plugins de Maven deberían incluir una directiva como "Provide(groupId:artifactId:version:format)" tal que "yum install org.apache.velocity:velocity" encontrará e instalará correctamente el paquete Velocity. La segunda parte de este proyecto consistiría en crear un plugin de Maven que solicite la instalación, mediante PackageKit, del paquete que proporciona la dependencia.

Contactos: Stanislav Ochotnicky o Alexander Kurtakov

Mentor(es):

Nota: Se requieren conocimientos básicos de Maven y RPM.

Estado: Propuesto

Resumen de la idea: Agregar dependencias rpm generadas automáticamente para los servicios relacionados con kde/plasma (consulte también el apunte del blog sobre el tema), y agregar ganchos de packagekit para usarlos (un ejemplo concreto sería para los motores de datos de plasma (consulte también el apunte de blog sobre el tema).

Contacto: Rex Dieter

Mentor(es):

Notas: Conocimientos intermedios de codificación de plasma rpm y/o kde

Estado: Propuesto

Resumen de la idea: Agregar un complemento de yum que utilice avahi para encontrar réplicas locales de los repositorios canónicos, y herramientas/scripts para que los servidores HTTP/NFS locales anuncien su disponibilidad. También sería conveniente incluir soporte completo para repositorios NFS en yum o en un complemento, de modo que los repositorios anunciados puedan estar en sistemas de archivos NFS que no estén montados localmente en los clientes. El uso en los clientes debería ser transparente, sin necesidad de modificar la configuración del repositorio yum local, salvo quizás la instalación/habilitación del plugin. Posteriormente, también se podría configurar Anaconda para que utilice avahi en la búsqueda de repositorios para la instalación.

Contactos: Roland McGrath

Mentor(es):

Notas: Divisible en varias piezas separadas que tienen valor por sí mismas.

Estado: Propuesto (por favor, revise)

Resumen de la idea: La idea principal es que Yum pueda detectar cuándo una actualización de paquete va a afectar alguna funcionalidad importante del sistema debido a una dependencia con otro paquete que no se actualizará (por ejemplo: Yum no detecta la actualización del kernel porque el kernel anterior no se elimina y la dependencia no se rompe). Esto ocurre ocasionalmente con el kernel y paquetes de terceros que brindan soporte para dispositivos que Fedora no admite directamente debido a restricciones de licencia: por ejemplo, Fedora actualiza el kernel y los paquetes RPM Fusion relacionados con la conexión inalámbrica Broadcom suelen tardar entre 2 y 4 días en actualizarse, lo que provoca que la conexión inalámbrica deje de funcionar.

Contactos:

Mentor(es):

_Notas: _ No me siento calificado para ser mentor/a.

Mezclar paquetes estables e inestables (es decir, de diferentes repositorios) es bastante engorroso y prácticamente inviable para más de unos pocos paquetes. Lo que falta es algo como el enfoque de Gentoo, donde se pueden desenmascarar (o enmascarar) ciertos paquetes inestables para que se descarguen e instalen en un entorno que, de otro modo, solo usaría paquetes estables. El usuario debe resolver cualquier conflicto que pueda surgir.

Además de la ventaja de tener acceso a paquetes más recientes, esto podría incentivar a más usuarios a probar paquetes inestables. Con políticas modificadas que solo permiten actualizaciones estables y la adaptación de versiones anteriores a una versión estable de Fedora, Fedora seguiría siendo atractiva para quienes prefieren trabajar con los paquetes más recientes, pero evitan usar sin formato por diversos motivos.

Estado: Propuesto

Resumen de la idea: Compartir metadatos de yum entre los usuarios de un sistema y también obtenerlos más rápidamente en lugar de descargar el fragmento completo cada vez.

Se propuso un sistema de almacenamiento de metadatos basado en Git propuesto, pero los responsables de Yum lo rechazaron. Podría haber otras maneras de hacerlo, como se sugiere en el informe de error, o bien, seguir adelante con la idea de Git; creo que es posible.

Contactos:

Mentor(es):

Estado:

Resumen de la idea: smock es una solución alternativa que Dan y yo desarrollamos hace unos años para crear una cadena de RPM en mock. Calcula todas las dependencias y compila los paquetes en el orden correcto, utilizando el resultado de una compilación anterior para satisfacer las dependencias en una compilación posterior, y de forma casi completamente automatizada. Lo que realmente se necesita es que el mock se amplíe para admitir esta funcionalidad de forma nativa.

Contactos:

Mentor(es):

Notas:

Estado: En progreso.

Resumen de la idea: Aquí buscamos un par de estudiantes con experiencia en empaquetado RPM, Python y Bash. Esta sería una buena oportunidad para profundizar en el empaquetado y el ecosistema de colaboradores de Fedora.

Este es un trabajo en progreso y los detalles se pueden encontrar aquí: http://fedoraproject.org/wiki/SIGs/FedoraMedical

Nos centraremos principalmente en el empaquetado y su publicación en el repositorio de Fedora. Sin embargo, también realizaremos algunas tareas de herramientas y trabajos relacionados. Por lo tanto, se requerirán Python y Bash.

Se requiere comprender las directrices para el mantenimiento de paquetes de Fedora. Se valorará la existencia de paquetes en Fedora. Además, el estudiante debería estar interesado en mantener algunos de esos paquetes después del SOC.

Contacto: Susmit Shannigrahi

Mentores: Susmit y Mario Ceresa

Notas:

Estado: Propuesto

Resumen de idea: La idea es crear una versión más intuitiva para estudiantes. Debería incluir herramientas para trama gráfica, un simulador de circuitos, quizás una aplicación para resolver ecuaciones, un IDE para programación básica y algunos compiladores que se enseñan en la universidad, entre otros recursos relevantes. Debería incluir documentación extensa para ayudar a los estudiantes a usar estas herramientas y Linux en general. Sería una ventaja contar con algunos juegos interesantes y un reproductor de música.

Además, si es posible, uno puede imaginar que se mostrara una pantalla durante la instalación lo cual ayudaría a seleccionar la edad del estudiante. Las aplicaciones se pueden instalar según corresponda. Por ejemplo, me gustaría tener un juego de Scrabble para un niño pequeño y luego un simulador de circuitos.

Contacto: Ryan Rix

Mentor: Ryan Rix (Maybe)

Estado: Propuesto

Resumen de la idea: Crear una aplicación educativa que presente el software de Fedora Robotics Suite

El Fedora Robotics SIG crea un Robotics Suite que incluye numerosos paquetes útiles en robótica. Queremos desarrollar una aplicación de demostración que presente a los nuevos usuarios, paso a paso, paquetes básicos como Fawkes y Player/Stage. Presentaría múltiples niveles similares a los de un juego, de complejidad creciente. La tarea general sería indicar al robot que realice una tarea específica en un entorno de simulación.

Para desarrollar esto se requieren sólidos conocimientos de C++. Se valora la experiencia en robótica, aunque no es imprescindible. Debes familiarizarte rápidamente con el nuevo software. Las partes visibles para el usuario requerirán programación IGU con Gtkmm.

Contactos: Tim Niemueller

Mentor: Tim Niemueller

Estado: Propuesto

Resumen de la idea: Contribuir a Dorrie y hacerlo más utilizable, probado y fácil de desplegar.

Más información en el Dorrie, código en https://github.com/shreyankg/Dorrie, bifurca y envía una solicitud de extracción si estás interesado en contribuir.

Contacto: Shreyank Gupta

Mentor: Shreyank Gupta

Estado: Propuesto

Sumerio de la idea: Contribuir a la familia de proyectos Aeolus (http://aeolusproject.org), comenzando con el empaquetado de dependencias que aún no están en Fedora (http://www.aeolusproject.org/page/Packages_Missing_From_Fedora)

Contacto: Chris Lalancette <clalance@redhat.com>

Mentor/a: Chris Lalancette <clalance@redhat.com>