Lines Matching refs:est
12 el proceso puede en ocasiones resultar desalentador si no se está
26 Esta documentación asume que está usando ``git`` para preparar sus parches.
27 Si no está familiarizado con ``git``, le recomendamos que aprenda a
49 pregunte al maintainer si el árbol no está listado allí.
83 Una vez establecido el problema, describa lo que realmente está haciendo
85 lenguaje sencillo para que el revisor verifique que el código se está
156 divida la etiqueta en varias líneas, las etiquetas están exentas de la
198 está bien. Simplemente incluya que **"este parche depende del parche X"**
233 - ERROR: cosas que es muy probable que estén mal
249 subsistema en el que está trabajando, Andrew Morton
260 Muchas listas relacionadas con el kernel están alojadas en vger.kernel.org;
302 los cambios que está enviando. Es importante para un desarrollador kernel
303 poder "citar" sus cambios, utilizando herramientas estándar de correo
309 es muy recomendable. Un tutorial interactivo para ``git send-email`` está
326 Excepción: si su proveedor de correo está destrozando parches, entonces
343 "changelog" para que el próximo revisor entienda lo que está pasando.
345 Asegúrese de decirles a los revisores qué cambios está haciendo y de
375 También está bien volver a enviar el parche o la serie de parches después
421 soy consciente, está cubierto por una licencia de código
500 coautor asociado. Se mantiene el procedimiento estándar, es decir, el orden
538 etiqueta Reported-by. La etiqueta está destinada a errores; por favor no la
654 área o subsistema del kernel está siendo parcheado.
669 podrá ver rápidamente cuando, dos o tres meses después, estén pasando por
818 Si está utilizando ``git format-patch`` para generar sus parches, puede
852 Si no está utilizando git para dar forma a sus parches, aún puede incluir