tag - que es un repositorio git
Gestión de proyectos para ir con GitHub (14)
(EDITAR: Esta pregunta ahora está desactualizada para mi problema en particular, ya que Google Code admite git ahora y he convertido Buffers de Protocolo a Mercurial de todos modos. Sin embargo, sigue siendo de interés general, IMO).
El puerto de Buffers de My C # Protocol usa github para su control de fuente, y estoy empezando a disfrutar realmente de usar git. Sin embargo, hasta donde puedo decir, github no proporciona ninguna herramienta de gestión de proyectos: seguimiento de defectos y funciones, discusiones, solicitudes de funciones, documentos, etc. Dada mi afiliación, Google Code sería una elección natural, pero me parecería extraño crea un proyecto allí pero aloja la fuente en github.
Esta pregunta sobre Fogbugz / Assembla parece enfocarse principalmente en el seguimiento de defectos. Me preguntaba qué experiencias han tenido otros cuando se trata de una solución de gestión de proyectos más "completa". ¿Fogbugz realmente hace todo lo que necesito? (Usar una wiki para documentos tiene sus ventajas, aunque también quiero poder distribuir documentación con el código.) Más allá de las características explícitas mencionadas en el primer párrafo, ¿hay otros aspectos del proyecto que debería considerar que me haya pasado por alto?
Esto definitivamente será un proyecto de código abierto, y aunque prefiero no pagar, no me importa si se requiere una pequeña tarifa. Actualmente soy el único desarrollador, pero eso puede cambiar y es muy posible que haya muchas personas que presenten errores y solicitudes de funciones. (En otras palabras, espero y espero que sea popular, pero conmigo haciendo la mayor parte del trabajo).
Anteriormente, contribuí en varios proyectos de código abierto, pero no he hecho mucho en la forma de ejecutar uno muy visible y activo. ( MiscUtil todavía está "alojado" en mi sitio web, con lanzamientos ocasionales; el control de fuente real está en mi NAS local).
¿Alguien quiere compartir sus experiencias?
EDITAR: Otra opción que ahora estoy considerando es un proyecto de Google Code (realmente me gustaría ser leal a mi empleador) y una fusión ocasional de git a svn (al menos, cada vez que hago un lanzamiento). Esto permitiría a los usuarios que no usan git obtener fácilmente la fuente también.
¿Has considerado CodePlex?
¿Has considerado a Trac ?
Parece haber una revisión "entusiasta" de una integración de git-Trac .
No tengo experiencia personal con estas herramientas, pero es posible que desee verificar la integración.
En el trabajo, utilizamos FogBugz y, en mi opinión, es la mejor herramienta de su tipo. Lo usaría para los proyectos sin ánimo de lucro en los que trabajo, excepto que es muy caro más allá de 2 usuarios.
Para los proyectos sin fines de lucro, utilizamos Lighthouse para el seguimiento de problemas. Está bien por lo que cuesta, y francamente no puedo encontrar ninguna alternativa adecuada dentro de su rango de precio. El seguimiento de problemas de Trac es un poco mejor que el de Bugzilla ... Sé que mucha gente ama a Trac, pero me parece muy inflexible. Las deficiencias de Trac nos llevaron a Lighthouse.
Mis proyectos sin fines de lucro posiblemente miren a bitbucket.org . Además del seguimiento de problemas, nos permitiría consolidar nuestros repositorios allí desde beanstalkapp.com, así como agregar una wiki.
Dicho todo esto, si FogBugz-on-Demand tuviera precios remotamente similares a los de Lighthouse.app para pequeños usuarios, me trasladaríamos allí en un abrir y cerrar de ojos. Cuando usas FB en el trabajo y luego Lighthouse.app por la noche ... usar Lighthouse parece que tu brazo ha sido cortado.
GitHub recientemente introdujo un rastreador de problemas propio; Sin embargo, no he realizado un análisis competitivo para determinar cómo se compara con otras opciones mencionadas en este hilo.
Si piensas que realmente serás el único desarrollador , Fogbugz te ayudará a mantener tu cordura. Fogbugz es un gran producto, construye comunicaciones enfocadas y puede convertir cualquier cosa en un caso (problema). Hace todo eso tan bien como cualquier sistema que he visto.
Pero su orientación es la comunicación comercial eficiente entre los usuarios y el soporte técnico, mejorar la confiabilidad de los horarios, enfocarse y priorizar lo que se está trabajando, discusiones internas y externas separadas, algunos buenos informes para rastrear que las cosas se están manejando. (La única crítica que se me ocurre es que no incluye el bloqueo de casos y el seguimiento de dependencias, lo que es realmente útil para esos errores enterrados en profundidad).
Poco de este conjunto de características lo ayudará a construir un proyecto de código abierto activo, con una comunicación abierta y animada y la necesidad de construir una comunidad y hacer que los usuarios evolucionen en desarrolladores a medida que el proyecto crezca. Entonces, si es allí donde desea terminar, es posible que realmente desee los canales de comunicación menos enfocados de uno de estos ligeros sistemas de rastreo.
Todavía no he utilizado Google Code en un proyecto, pero en términos de comunicación transparente y abierta, parece ser un buen soporte para un proyecto de código abierto activo. Además, ya lo sabes. Si desea aumentar la participación en su proyecto, el código de Google parece ser el camino a seguir.
Sugeriría JavaForge como alternativa, ya que tiene todo lo que buscas:
- Ofrece alojamiento gratuito con Mercurial y Git (o mixto).
- Su rastreador de problemas está a años luz de GitHub. Es extremadamente potente y personalizable, puede rastrear requisitos, solicitudes de funciones, errores, tareas, etc.
- Proporciona administración de documentos, también con acceso WebDAV (compartiendo tan fácil como con las carpetas compartidas).
- Tiene una wiki incorporada para la creación colaborativa de documentación, requisitos, etc.
- Tiene foros para discusiones.
Tenga en cuenta que el sitio está impulsado por codeBeamer , nuestro producto comercial probado en batallas por compañías globales.
(Descargo de responsabilidad: somos un proveedor comercial de soluciones ALM ágiles).
También podría intentar usar una herramienta como BusyFlow . Allí puede hacer un seguimiento de las confirmaciones de GitHub y comentarlas (los comentarios se sincronizan con GitHub). Para otras facetas de gestión de proyectos, BusyFlow se integra con Google Calendar, Trello, Basecamp, Pivotal Tracker, etc. De modo que puede ver sus elementos de GitHub junto con tareas, archivos y eventos del calendario.
(Descargo de responsabilidad: soy cofundador de BusyFlow).
Usamos bitbucket.org , que no es GIT, es Mercurial *, pero tiene un seguimiento de errores / problemas por rama, etc.
Creo que puede ser muy útil integrar estas cosas con el lugar donde administras tu código fuente para hacer referencias cruzadas a cosas como el número de problema en un mensaje de confirmación. O Mensaje fijo para un problema que contiene el número de revisión del código. Perderías esto si eliges un BTS diferente como el código de Google. Como se menciona en otra respuesta, Trac es realmente bueno en la integración.
Editar: Debo decir que para mi proyecto de código abierto más utilizado, en realidad lo tenemos en:
- Bitbucket (gestión del código fuente)
- Launchpad (informe de errores de usuario, gestión de traducciones)
- Trac auto-alojado (wiki, seguimiento de problema de proyecto y desarrollador, espejo de código fuente)
- Código de Google (descargas de archivos)
Y sé que esto suena loco, pero escogemos y elegimos los mejores fragmentos de cada servicio. Y sorprendentemente nadie se queja.
* cual es mejor en mi opinión de todos modos, pero por favor no me llame.
Uso GitHub junto con Lighthouse para el seguimiento de problemas. Es un poco barebones en comparación con algunas de las otras opciones, pero al mismo tiempo funciona muy bien si solo quieres una herramienta liviana de la que no tengas que preocuparte demasiado. Se puede integrar con GitHub si lo desea, y también es gratis para proyectos de código abierto.
Uso github y google code en algunos lugares. El rastreador de problemas del código de Google es lo suficientemente decente, pero no puedo lidiar con la subversión.
Eche un vistazo a mi cliente de memcached de java para ver un ejemplo de esto, particularmente la pestaña de fuente en la parte superior.
Yo también uso github con Lighthouse. Y si su mensaje de confirmación contiene algo así como
[# 32 estado: resuelto]
Lighthouse resolverá el ticket n. ° 32 contra la confirmación, que considero rápido y útil. Aparte de eso, Lighthouse es un poco ... er, ligero en características.
Mingle admite git a través del complemento mingle_git . Mingle tiene una licencia comunitaria gratuita para proyectos de código abierto.
<plug> Estoy construyendo el aeropuerto . </plug>