Diferencia entre revisiones de «Iteración 4 (27/10/2014)»
De Wiki de EGC
(→Trabajo Realizado) |
(→Trabajo Realizado) |
||
| (No se muestran 2 ediciones intermedias del mismo usuario) | |||
| Línea 2: | Línea 2: | ||
* Gestión de ramas: | * Gestión de ramas: | ||
| − | + | ** Para el proyecto entero, hemos pensado que sería una buena opción hacer una rama por motivos físicos, es decir, una rama por cada subgrupo perteneciente al proyecto, pudiendo haber dos o más subgrupos que compartan una misma rama en caso de que la funcionalidad sea compartida. | |
| − | **Para el proyecto entero, hemos pensado que sería una buena opción hacer una rama por motivos físicos, es decir, una rama por cada subgrupo perteneciente al proyecto, pudiendo haber dos o más subgrupos que compartan una misma rama en caso de que la funcionalidad sea compartida. | + | ** Dentro de nuestro subgrupo, pensamos que debería haber una rama por motivos organizacionales, es decir, una rama por cada tarea para organizarnos dentro del equipo. También podrían existir ramas por motivos de entorno, en el caso de que decidiéramos cambiar, por ejemplo, el tipo de la base de datos. |
| − | + | ** En cuanto a la política sobre los ''merge'', hemos decidido que sólo se hará merge de una tarea con la baseline cuando dicha rama se considere completa y sin errores. En caso de ser una rama generada debido a algún motivo de entorno, se realizará merge cuando se consiga hacer funcionar la baseline en dicho entorno. | |
| − | **Dentro de nuestro subgrupo, pensamos que debería haber una rama por motivos organizacionales, es decir, una rama por cada tarea para organizarnos dentro del equipo. También podrían existir ramas por motivos de entorno, en el caso de que decidiéramos cambiar, por ejemplo, el tipo de la base de datos. | + | ** Una rama se eliminará cuando se realice un merge de esa rama. |
| + | ** Por último, con respecto a los permisos de usuarios, dentro de la rama perteneciente a nuestro subgrupo , todos tendremos el máximo nivel de permiso sobre todas las ramas y subramas. | ||
== Asistentes == | == Asistentes == | ||
Revisión actual del 18:39 27 oct 2014
Trabajo Realizado
- Gestión de ramas:
- Para el proyecto entero, hemos pensado que sería una buena opción hacer una rama por motivos físicos, es decir, una rama por cada subgrupo perteneciente al proyecto, pudiendo haber dos o más subgrupos que compartan una misma rama en caso de que la funcionalidad sea compartida.
- Dentro de nuestro subgrupo, pensamos que debería haber una rama por motivos organizacionales, es decir, una rama por cada tarea para organizarnos dentro del equipo. También podrían existir ramas por motivos de entorno, en el caso de que decidiéramos cambiar, por ejemplo, el tipo de la base de datos.
- En cuanto a la política sobre los merge, hemos decidido que sólo se hará merge de una tarea con la baseline cuando dicha rama se considere completa y sin errores. En caso de ser una rama generada debido a algún motivo de entorno, se realizará merge cuando se consiga hacer funcionar la baseline en dicho entorno.
- Una rama se eliminará cuando se realice un merge de esa rama.
- Por último, con respecto a los permisos de usuarios, dentro de la rama perteneciente a nuestro subgrupo , todos tendremos el máximo nivel de permiso sobre todas las ramas y subramas.
Asistentes
- Cristian Fernández Rivas
- Miguel Ángel Núñez-Romero Olmo
- David Letrán González
- Cristina Padilla Carrero
- Carlos López García
- Luis Pintado Lozano
