Lines Matching full:se

12 el proceso puede en ocasiones resultar desalentador si no se está
14 que pueden aumentar considerablemente las posibilidades de que se acepte su
40 que se puede descargar con::
64 evidentes. Incluso si se detectó un problema durante la revisión del
78 CPU, memoria y legibilidad; o, cuando se trata de heurísticas, entre
85 lenguaje sencillo para que el revisor verifique que el código se está
86 comportando como se pretende.
89 formato que se pueda incorporar fácilmente en la gestión del código fuente
98 descripción completa del parche y justificación del mismo. No se limite a
112 Si desea hacer referencia a un commit específico, no se limite a hacer
114 del commit, para que sea más fácil para los revisores saber de qué se
130 cambio se pueden encontrar en la web, agregue las etiquetas 'Link:' que
137 Cuando se vincule a archivos de listas de correo, preferiblemente use el
151 como se envió.
163 Las siguientes configuraciones de ``git config`` se pueden usar para
202 asegurarse de que el kernel se compila y ejecuta correctamente después de
220 Una excepción importante es cuando se mueve código de un archivo a otro.
255 esta lista ha hecho que muchos desarrolladores se desconecten. Busque en el
275 parche a security@kernel.org. Para errores graves, se debe mantener un
291 maintainer de las MAN-PAGES (como se indica en el archivo MAINTAINERS) un
293 que alguna información se abra paso en las páginas del manual. Los cambios
323 archivo adjunto MIME, disminuyendo la probabilidad de que se acepte su
337 maneras en que se pueda mejorar el parche, en forma de respuesta a su
347 agotador y lento, y los revisores a veces se ponen de mal humor. Sin
361 No se desanime o impaciente
382 serie de parches: "RESEND" solo se aplica al reenvío de un parche o serie
404 en parches que se envían por correo electrónico.
420         (b) La contribución se basa en trabajo previo que, hasta donde yo
426             tal y como se indica en el documento; o
444 anónimas). Esto se hará por usted automáticamente si usa ``git commit -s``.
456 de cómo se propagó a los maintainers y, en última instancia, a Linus, con
464 desarrollo del parche, o que él/ella se encontraba en el camino de entrega
469 entonces puede pedir que se agregue una línea Acked-by: al registro de
490 Esta es la única etiqueta que se puede agregar sin una acción explícita por
491 parte de la persona a la que se nombre - pero debe indicar que esta persona
496 desarrolladores; se utiliza para dar atribución a los coautores (además del
500 coautor asociado. Se mantiene el procedimiento estándar, es decir, el orden
502 parche en la medida de lo posible, independientemente de si el autor se
536 encuentran errores y los reportan. Por favor, tenga en cuenta que si se
541 Una etiqueta Tested-by: indica que el parche se probó con éxito (en algún
543 de que se han realizado algunas pruebas, proporciona un medio para ubicar
569 no hago (a menos que se indique explícitamente en otro lugar) ninguna
578 revisión que se ha hecho en el parche. Las etiquetas Reviewed-by, cuando
588 general, se debe mencionar la eliminación de las etiquetas Tested-by o
596 si diligentemente acreditamos a los reporters de ideas, con suerte, se
600 anterior. Esto se utiliza para facilitar descubrir dónde se originó un
619 parche con formato adecuado se puede obtener con ``git format-patch``. Las
633   - El cuerpo de la explicación, línea envuelta en 75 columnas, que se
651 secuencia se rellena con ceros, el orden numérico y alfabético es el mismo.
663 Tenga en cuenta que la ``frase de resumen`` de su correo electrónico se
664 convierte en un identificador global único para ese parche. Se propaga por
665 hasta el registro de cambios de ``git``. La ``frase resumida`` se puede
666 usar más adelante en discusiones de desarrolladores que se refieran al
680 etiquetas no se consideran parte de la frase de resumen, pero describen
682 descriptor de versión si las múltiples versiones del parche se han enviado
688 desarrolladores entiendan el orden en que se deben aplicar los parches y
705 la línea ``From:`` del encabezado del correo electrónico se usará para
715 con tal detalle que cuando se lea semanas, meses o incluso años después,
717 razonamiento de **por qué** se creó el parche.
734 ``-p 1 -w 70`` para que los nombres de archivo se enumeran desde la parte
747 versión no forma parte del registro de cambios que se incluye con el árbol
748 git. Es información adicional para los revisores. Si se coloca encima de la
750 debajo de la línea de separación, se quita automáticamente al aplicar el
801 forma, varias versiones del parche no se convierten en un inmanejable
850     La función ``--base`` se introdujo en la versión 2.9.0 de git.
854 árbol en que se basa su trabajo. Debe agregarlo en la carta de presentación