Lines Matching refs:su

13 trabajar con el y en su desarrollo. El documento no tratará ningún aspecto
23 kernel de Linux? Tal vez su jefe le haya dicho, "Escriba un driver de
60 la forma de hacer las cosas en su empresa.
215 para incluir su parche en el árbol del kernel de Linux, y posiblemente
247 https://kernel.org o en su repo.  El proceso de desarrollo es el siguiente:
266     deben ser enviado a una lista de correo pública para su revisión.
306 desarrolladores de subsistemas del kernel --- exponen su estado actual de
333 con el árbol principal, necesitan probar su integración. Para ello, existe
409 Si varias personas responden a su correo, el CC (lista de destinatarios)
418 superior de su respuesta, y agregue sus declaraciones entre las secciones
422 Si incluye parches en su correo, asegúrese de que sean texto legible sin
425 parches comprimidos; y pueden querer comentar líneas individuales de su
428 prueba es enviarse el correo a usted mismo, e intentar aplicar su
429 propio parche. Si eso no funciona, arregle su programa de correo o
438 posible. Cuando envíe un parche para su aceptación, se revisará en sus
447 Recuerde, esto es parte de introducir su parche en el kernel. Tiene que ser
451 a su publicación, espere unos días e intente de nuevo, a veces las cosas se
456   - esperar que su parche se acepte sin preguntas
463 cooperativo y estar dispuesto a adaptar su idea para que encaje dentro
464 del kernel, o al menos esté dispuesto a demostrar que su idea vale la pena.
468 Es normal que las respuestas a su primer parche sean simplemente una lista
469 de una docena de cosas que debe corregir. Esto **no** implica que su
471 los problemas planteados en su parche, y envié otra vez.
529 ellos, y no simplemente usándolos como un vertedero para su función. Sin
531 su serie de parches debe casi siempre ser más pequeña que eso.
536    aplicados, ya que no requieren mucho tiempo o esfuerzo para verificar su
556 	presentaría su trabajo intermedio antes de tener la solución final.*
564 elegante y trabajar junto a la comunidad, discutiendo su trabajo inacabado.
566 "feedback" y mejorar su trabajo, pero también mantenga sus cambios en
567 pequeños trozos que pueden ser aceptados, incluso cuando toda su labor no
570 También tenga en cuenta que no es aceptable enviar parches para su
584 texto de su correo electrónico. Esta información se convertirá en el
589   - el diseño general de su propuesta
614 Alex Shepard por su revisión, comentarios y contribuciones. Sin su ayuda,