forked from V1rd/ReanEmu
/
PLANIFICACION
134 lines (116 loc) · 6.22 KB
/
PLANIFICACION
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
== ReanEmu ==
#####################################################################
## Planificacion de repositorios y de Avances del nuevo emulador ##
#####################################################################
La planificacion y organizacion adecuada de la informacion como del
equipo y repositorios es uno de los aspectos mas importantes para
lograr el objetivo con este proyecto de manera que:
Cada commit se llevara a cabo con los avances individuales por
repositorios en commits personales y por cada una de las cosas
minimas que hagan referentes al mismo tema y se clasificaran tambien
con una tag para que asemeje a un solo topico en concreto:
Nombre: Descripcion
------ -----------
Spell: texto
Script: texto
Instance: texto
Quest: texto script sql
Reputacion: texto script sql
SQL: dependiendo
Todos los commits seran en ESPAÑOl, excepto los nombres referentes
a cosas del emulador como tal, spells, nombres de las mismas, nombres
de archivos, dependencias, etc. Los nombres de archivos que describan
los cambios en sql, serán en inglés y se ajustarán a la cronologia de
tc en la carpeta sql/update, ya sea en world, characters o auth de
acuerdo a lo que corresponda cada query o grupo en concreto asi:
año-mes-dia-numero mayor a 100_carpeta_texto_explicativo.sql
--- --- --- ------------------ ---------------------------------------
2011_09_01_102_world_OutdoorPvPWG_bunners.sql
Ojo, siempre mayor a cien, para no pisar cualquier commit de tc. Otra
cosa que hay que tomarse en cuenta es el hecho de que si algo es de
codigo de otra persona o equipo de personas en concreto hay que
mencionarlo por los copyrights, y si nosotros hacemos algo que no lo
haya hecho nadie, añadir el copyright respectivamente de cada uno
individualmente y de Power of Communities, sobre todo si en una script
se le ha hecho mejoras notables y de peso.
* Copyright (C) ReanEmu 2011 <https://github.com/eilo/ReanEmu>
Esto tambien nos servira para añadirlo al What_Is_Inside del repo
De ahora en adelante hay q tener una estructura ordenada y simple
de manera que no nos pisemos las cosas y mucho peor, tratar de
unirlas, porque tampoco es necesario unir todas las branches entre si.
La modalidad de branches estara en 3 grupos asi:
1 2 3
----------- --------------------------------- ------
(tc)&(warden) (eilo)&(jesus)&(ws)->(experimental) (master)
De manera general:
----------------
--Primer Grupo--
----------------
tc: se actualiza solo con cosas de TC y no se mezcla aqui, nada
de lo del resto de repos, es decir una tc limpia tal cual.
Tag -> (tc)
warden:esta lleva solo lo de warden, nada mezclado aqui, es decir
una warden limpia.
Tag -> (warden)
-----------------
--Segundo Grupo--
-----------------
Estas branches seran hechas a partir de experimental en las cuentas
personales de git de cada uno, sin embargo los commits se haran sobre
el branch experimental del repo.
eilo: esta sera mi branch personal, aqui hare y deshare lo que sea
necesario para mi o a mi criterio. Siempre comentare cada accion
con un commit individual por mas chorra que sea. Dado que en
algun momento se necesita revertir, por que no funcione bien o
porque tc lo arreglase en algun momento. Se mantendra el
codestyling de espacios en blanco con espaciadora, nunca con
tabs en el codigo o el emulador se aloca. siempre se comunicara
al resto de devs que es lo que se esta haciendo y se tendra
claro siempre los repos que a cada uno se le ha asignado. Si
algun commit tiene referencia a alguno de los repos de otro dev,
es imprescindible comunicarlo. Cada uno tendra un What Is inside
individual, y cada branch de cada developer saldra a partir del
branch merge.
jesus:branch personal de jesus que tiene q ir con las mismas condiciones
citadas arriba, todas y cada una. Se depreca el cherry pick por
razones de conflictos anteriores, y se lo permitirá unicamente con
un commit contemporaneo, es decir que no supere 1 dia atras de la
revision punta (head) que tengamos nosotros.
ws: Exactamente las mismas condiciones expuestas en los dos parrafos
anteriores, y cada cosa que se quiera hacer se debe hablar con los
otros dos en caso de que este hecho o no, y mantener al dia el what
is inside de cada uno. Es importante tener una copia del repo
individual vuestro y otra copia del repo de rean limpio para swichear
branches y visualizar sin problema el panorama claramente.
experimental: Aqui se unirá cada cierto tiempo todo el material que
consideremos como "funcional" de cada uno de nuestros avances
de manera que aqui se haga las primeras pruebas y se pueda ver
los errores en conjunto. Este branch no es para solucionar
errores de los commits personales, es decir, si se equivocaron
un typo, lo corrigen en vuestro branch personal y una vez
corregido, lo traen al experimental. No al revés. Este branch irá
directo a ser probado en reino de pruebas para ir sacando el
changelog. Aqui en este branch se unificaran los What is inside
de cada uno de los individuales y se expondra como un solo archivo.
Cada vez q necesiteis revertir algo, se lo hara en el mismo
commit de cada uno y en su momento debera ser notificado al
respectivo developer y su causa. En este branch cada cierto tiempo
se va a ir pusheando tag->(tc) y tag->(warden) de manera que nos
mantengamos al dia con las branchs principales del emulador, ademas
de tener la tag visible en el log en experimental.
Tag -> (experimental)
----------------
--Tercer Grupo--
----------------
master: Aqui se comentará el trabajo final, por fechas, testeado en
experimental y que contenga la característica de estabilidad y
funcionalidad con el tag de Milestone#.#. En master vienen las
versiones finales, si ocurre algun fix para la version final,
tiene que pasar el respectivo proceso, por el repo de merge,
luego al individual de todos, y despues al experimental y
finalmente al master. De ninguna manera permitido al reves.
Tag -> (master) & [automatico]Tag -> (head)
El proceso en general se lograra hacer mas llevadero y sobre todo nos
ayudara para alcanzar esta meta inmensa como equipo de desarrollo de rean.
Saludos
Eilo