Lines Matching refs:se

11 KVM se esfuerza por ser una comunidad acogedora; las contribuciones de los
12 recién llegados son valoradas e incentivadas. Por favor, no se desanime ni
13 se sienta intimidado por la extensión de este documento y las numerosas
27 KVM x86 se encuentra actualmente en un período de transición de ser parte
33 Por lo general, las correcciones para el ciclo en curso se aplican
35 para el siguiente ciclo se dirige a través del árbol de KVM x86. En el
36 improbable caso de que una corrección para el ciclo actual se dirija a
37 través del árbol KVM x86, se aplicará a la rama ``fixes`` antes de llegar
40 Tenga en cuenta que se espera que este periodo de transición dure bastante
53 Todas las ramas temáticas, excepto ``next`` y ``fixes``, se agrupan en
55 decir, cuando se actualiza una rama temática. Como resultado, los push
64 Los cambios dirigidos a la siguiente versión se dirigen a través del árbol
79 Normalmente, los envíos se revisan y aplican en orden FIFO, con cierto
82 actual y/o árboles estables, consiguen saltar la cola. Los parches que se
87 Tenga en cuenta que la mayor parte de la revisión se realiza entre rc1 y
88 rc6, más o menos. El periodo entre la rc6 y la siguiente rc1 se utiliza
124 historia de KVM, por ejemplo, la versión candidata en la que se basa
131 Cuando se trata de estilo, nomenclatura, patrones, etc., la coherencia es
135 Con algunas advertencias que se enumeran a continuación, siga las
197 **¡NO use x86/kvm!** ``x86/kvm`` se usa exclusivamente para cambios de
202 temáticas se preocupan mucho más por los conflictos de código).
223 no se ande con rodeos.
242 parches. que se dirigen principalmente a código arch/x86 que _NO_ es código
246 por varias razones. En primer lugar, el código que realmente se está
252 Para la revisión inicial, se podría argumentar que "lo que está roto" es
281 seleccionados automáticamente se retroportan, pero requieren la aprobación
286 Cuando se mencione una función en un comentario, registro de cambios o
302 modificar los comentarios. Siempre que sea posible y pertinente, se
308 afecten al código MMU común de KVM, se recomienda encarecidamente ejecutar
309 con TDP deshabilitado. Para todos los demás cambios, si el código que se
314 tienen fallos conocidos. Si sospecha que un fallo no se debe a sus cambios,
315 verifique que el *exactamente el mismo* fallo se produce con y sin sus
330 por ejemplo, si la cobertura se proporciona mediante la ejecución de una
332 autoprueba de kernel relacionada en una VM, pero en todos los casos se
335 de hardware, ya que los flujos de errores y excepciones rara vez se
351 qué tipo de feedback se solicita/espera. No abuse del proceso de RFC; las
362 se recomienda encarecidamente que se faciliten pruebas de regresión para
382 ``In-Reply-To:`` se convierte en un lío para grandes series y/o cuando el
394 que condujeron al parche. El contexto de por qué se hizo un cambio es muy
404 Tenga en cuenta que ``--base=auto`` funciona como se espera si y sólo si el
405 upstream de una rama se establece en la rama temática base, por ejemplo,
406 hará lo incorrecto si su upstream se establece en su repositorio personal
420 en las pruebas se ordenarán después de las actualizaciones de las
426 se confunden cuando los parches de una serie se aplican en diferentes
433 Cuando se acepte oficialmente un parche/serie, se enviará un correo
439 Si se aplica un subconjunto de parches, se indicará claramente en la
440 notificación. A menos que se indique lo contrario, se sobreentiende que
444 Si por alguna razón se retira un parche después de haber sido aceptado
445 oficialmente, se enviará una respuesta al correo electrónico de
446 notificación explicando por qué se ha retirado el parche, así como los
452 es *normalmente* estable una vez que se ha enviado una notificación, pero
453 ocurren cosas. En la mayoría de los casos, se proporcionará una
454 actualización del correo electrónico de notificación si se aplica un SHA1
456 ramas de KVM x86 necesitan ser rebasadas, no se darán notificaciones