Zen

Translation

English type: Plain text
*Unmaintained Or Unresponsive Upstream Projects*:
In cases where upstream projects are either unmaintained or unresponsive,
it might be acceptable to patch the software.
If upstream is unmaintained,
you might want to consider sharing patches with other distributions
or taking over maintenance
if you have the time, skills, and interest.
Be wary of maintaining software with no upstream
since all the burden of maintaining the codebase
as well as packaging issues are with you.
If upstream is unresponsive and many distributions are deviating significantly,
it might be a opportunity for a cross distribution fork
(Similar to XFree86 and Xorg).
708/6450 · 645

Sign in to save the translation.

English Spanish Actions
*ABI or API Deviations*:
Patches that introduce a new application binary interface (ABI)
or application program interface (API)
must be especially avoided,
even if the ABI/API changes are planned to land upstream.
When these patches get upstream
(if ever),
upstream developers might introduce changes in the ABI/API
during the code review process before merging the code.
This could break other software in the repository
that makes use of the Fedora-patched ABI/API.
*Desviaciones ABI o API:*
Los parches que introducen una nueva interfaz binaria de aplicación (ABI)
o una interfaz de programa de aplicación (API)
deben evitarse especialmente,
incluso si se plantea que los cambios ABI/API lleguen upstream.
Cuando estos paquetes lleguen upstream
(sí alguna vez lo hacen),
los desarrolladores upstream pueden introducir cambios en la ABI/API
urante el proceso de revisión del código antes de fusionarlo.
Esto podría romper otro software en el repositorio
que hace uso de los ABI/API de Fedora parcheados.
*Direct End User Feedback*:
When users run into problems with any software that is in Fedora,
they can report the problems directly upstream.
By not deviating from upstream,
it remains a central location for all bug reports on that software,
leaving Fedora package maintainers to concentrate on good packaging
instead of acting in between users and upstream issues.
*Comentarios Directos del Usuario Final:*
Cuando los usuarios tienen problemas con cualquier software que esté en Fedora,
pueden informar de los problemas directamente upstream.
Al no desviarse del upstream,
mantiene una ubicación central para todos los informes de error en ese software,
lo que permite a los mantenedores de paquetes de Fedora concentrarse en un buen empaquetamiento
en lugar de actuar entre los usuarios y los problemas upstream.
Tips On Upstreaming Patches
Consejos Sobre la Actualización de Parches
Talk to upstream. Maintaining a regular flow of communication with the upstream project is helpful in understanding the upstream developers well, and encourages them to be more responsive to your requests. It also helps in understanding technical issues, such as how they prefer patches to be submitted.
Hablar upstream. Mantener un flujo regular de comunicación con el proyecto upstream es útil para comprender bien a los desarrolladores upstream y los alienta a ser más receptivos en sus solicitudes. También ayuda en el entendimiento de cuestiones técnicas como, por ejemplo, como prefieren que se envíen los parches.
Make the patches generic enough to be maintained by upstream developers. Explain the need for your patches, that is, what bugs they fix or what features they add. Any references to bugzilla reports or user requests can be quite useful for the developers who receive your patches.
Hacer los parches lo bastante genéricos para ser mantenidos por los desarrolladores upstream. Explicar la necesidad de sus parches, esto es, que errores corrigen o que nuevas características añaden. Cualquier referencia a los informes bugzilla o las peticiones de los usuarios pueden ser bastante útiles para los desarrolladores que reciben sus parches.
Do not consider any change to be too small to be sent upstream. Even minor changes like fixing a permission problem in a file or excluding an empty file can and should be reported upstream even if upstream does not necessarily act on all of them quickly.
No considere que cualquier cambio sea demasiado pequeño para enviarlo upstream. Incluso los cambios menores como la corrección de un permiso en un archivo o la exclusión de un archivo vacío puede y debería ser reportado upstream incluso en el caso que upstream no se actúe necesariamente sobre todos ellos rápidamente.
Divide patches into small and independent chunks that remain functional, so they can be understood, reviewed, and accepted or rejected individually.
Divida los parches en partes pequeñas e independientes que sigan siendo funcionales, de este modo ellos los pueden entender, revisar y aceptar o rechazar individualmente.
If the patch introduces new strings or changes existing ones, make the changes as generic as possible.
Si el parche introduce nuevas cadenas o cambia las existentes, haga los cambios tan genéricos como sea posible.
Fix your coding style to match the upstream project's guidelines. This might seem trivial but many upstream projects insist on following their guidelines so that their codebase looks internally self consistent and is more maintainable.
Corrija su estilo de escritura para que coincida con las directrices del proyecto upstream. Esto puede parecer trivial pero muchos proyectos upstream insisten en que se sigan sus directrices de modo que su código base parezca internamente consistente y sea más fácil de mantener.
Where possible, encourage upstream point-releases that fix bugs and security issues only, to avoid the possibility of regressions.
Siempre que sea posible, fomente las versiones puntuales upstream que corrigen errores y cuestiones de seguridad solo, para evitar la posibilidad de regresiones.
Test your changes as thoroughly as you can before you send them upstream. Broken patches leave a long-lasting bad impression.
Pruebe sus cambios lo más detalladamente posible antes de enviarlos upstream. Los parches rotos dejan una mala impresión duradera.
Be patient and cooperative. If feedback is offered, discuss changes, answer questions, and provide revisions that fix any problems. Don't flame or argue unnecessarily with upstream developers. The overall goal is persuade upstream developers to get your patches committed upstream and not to demonstrate "who is better." Don't forget the human element in these conversations. If necessary, we will have to carry some patches downstream to enforce our policies even if upstream does not agree with us at that point.
Sea paciente y cooperador. Si se ofrecen comentarios, analice los cambios, responda a las preguntas y proporcione revisiones que solucionen cualquier problema. No llame ni discuta innecesariamente con los desarrolladores upstream. El objetivo general es persuadir a los desarrolladores upstream para que envíen sus parches upstream y no demostrar "quien es mejor." No olvide el elemento humano en estas conversaciones. Si es necesario, tendremos que implementar algunos parches en sentido downstream para hacer cumplir nuestras políticas incluso si el nivel upsream no está de acuerdo con nosotros en ese momento.
Some Examples Of Exceptions
Algunos Ejemplos de Excepciones
*Severe Security Issues Or Major Bug Fixes*:
For any major issues such as security holes or data loss problems,
waiting on a new release from upstream can be too much of a delay.
In these instances, it may be better to backport those fixes from upstream
or fix the issue by writing your own patch
and do an update in Fedora.
If you are writing a new patch,
send it upstream so that Fedora shares the benefits
and avoid deviations in new releases that follow.
Be careful when expeding the patching however.
A security patch that is not comprehensive
can leave unexpected security holes still open
or a patch to fix a major problem can worsen the problem.
Get your patches peer reviewed as much as possible.
Due to differences in release schedules between upstream projects and Fedora releases,
maintainers would have to keep in mind feature and development freezes in Fedora
and fix problems accordingly.
*Cuestiones Graves de Seguridad O Correcciones de Errores Importantes:*
Para cualquier cuestión importante como agujeros de seguridad o problemas de pérdida de datos,
esperar un nuevo lanzamiento upstream puede ser demasiado retraso.
En estas circunstancias, puede ser mejor respaldar esas correcciones upstream
o solucionar el problema escribiendo su propio parche
y realizar una actualización de Fedora.
Si está escribiendo un nuevo parche,
envíelo upstream de manera que Fedora comparta los beneficios
y evite desviaciones en los nuevos lanzamientos que siguen.
Sin embargo, tenga cuidado al acelerar la aplicación de parches.
Un parche de seguridad que no esté completo
puede dejar agujeros de seguridad inesperados todavía abiertos
o un parche que corrige un problema importante puede empeorar el problema.
Haga que sus parches sean revisados por pares tanto como sea posible.
Debido a las diferencias de planificación de lanzamientos entre los proyectos upstream y los lanzamientos Fedora,
los encargados del mantenimiento tendrían que tener en cuenta los bloqueos de funciones y desarrollo en Fedora
y solucionar los problemas en consecuencia.
*Non-free or patent encumbered software*:
If upstream projects include software that is non-free or has known patent issues,
such software does not meet the xref:packaging-guidelines::LicensingGuidelines.adoc[Licensing Guidelines]
and Fedora will not include them.
In many instances, such code is optional in the form of plugins
that Fedora simply does not need to include
in its software repository.
In other cases,
it might be possible to work with upstream on making it optional
or patch specific portions.
*Software no libre o sujeto a patentes:*
Si los proyectos upstream incluyen software que no sea libre o que tenga problemas de patentes conocidos,
dicho software no cumple las xref:packaging-guidelines::LicensingGuidelines.adoc[Directrices de Licenciamiento]
y Fedora no lo incluirá.
En muchos casos, dicho código es opcional en forma de complementos
que Fedora simplemente no necesita incluir
en su repositorio de software.
En otros casos,
podría ser posible trabajar con upstream para hacerlo opcional
o parchear partes específicas.
*Unmaintained Or Unresponsive Upstream Projects*:
In cases where upstream projects are either unmaintained or unresponsive,
it might be acceptable to patch the software.
If upstream is unmaintained,
you might want to consider sharing patches with other distributions
or taking over maintenance
if you have the time, skills, and interest.
Be wary of maintaining software with no upstream
since all the burden of maintaining the codebase
as well as packaging issues are with you.
If upstream is unresponsive and many distributions are deviating significantly,
it might be a opportunity for a cross distribution fork
(Similar to XFree86 and Xorg).
*Proyectos Upstream Sin Mantenimiento o que no Responden:*
En los casos donde los proyectos upstream no tienen mantenimiento o no responden,
podría ser aceptable parchear el software.
Si el upstream no está mantenido,
es posible que desee considerar compartir parches con otras distribuciones
o hacerse cargo del mantenimiento si tiene tiempo, habilidades e interés.
Tenga cuidado con el mantenimiento del software sin upstream
ya que toda la carga de mantener el código base
y las tareas de empaquetado recaen sobre usted.
ISi el upstream no responde y muchas distribuciones se desvían significativamente
podría ser una oportunidad para una bifurcación de distribución cruzada.
(Similar a XFree86 y Xorg).
*Patches Heading Upstream*:
Any patches that are known to be headed upstream
_might_ be patched temporarily in Fedora
if the patches provide important bug fixes
or in rare cases, features to users.
If this is done,
maintenance effort of the patches should be low impact
for the small amount of time until upstream merges the patches
and does a new release.
 
*Distribution Integration*:
There are features that are critical or very good to have for Fedora as a distribution
but not been significant enough
for various upstream projects to accept related enhancements just yet.
Use your discretion carefully when choosing to integrate any such patches
since there is a trade off
between upstream acceptance and Fedora integration
and associated costs/benefits.
 
*Bundling of Libraries*:
Refer to the xref:packaging-guidelines::index.adoc#bundling[Bundling and Duplication of System Libraries] section of the Packaging Guidelines for details.
Fixes related to bundling should of course be sent upstream if possible.
 
References
 
http://fedoraproject.org/wiki/Objectives
 
xref:packaging-guidelines::index.adoc#_all_patches_should_have_an_upstream_bug_link_or_comment[All patches should have an upstream bug link or comment]
 
http://fedoraproject.org/wiki/PackageMaintainers/TrackingUpstream
 
http://fedoraproject.org/wiki/PackageMaintainers/TrackingDownstream
 

Loading…

User avatar vareli

Translation added

  1. fedora-docs-l10n/package-maintainers
  2. master/pages/Staying_Close_to_Upstream_Projects
  3. Spanish
*Unmaintained Or Unresponsive Upstream Projects*:
In cases where upstream projects are either unmaintained or unresponsive,
it might be acceptable to patch the software.
If upstream is unmaintained,
you might want to consider sharing patches with other distributions
or taking over maintenance
if you have the time, skills, and interest.
Be wary of maintaining software with no upstream
since all the burden of maintaining the codebase
as well as packaging issues are with you.
If upstream is unresponsive and many distributions are deviating significantly,
it might be a opportunity for a cross distribution fork
(Similar to XFree86 and Xorg).
*Proyectos Upstream Sin Mantenimiento o que no Responden:*
En los casos donde los proyectos upstream no tienen mantenimiento o no responden,
podría ser aceptable parchear el software.
Si el upstream no está mantenido,
es posible que desee considerar compartir parches con otras distribuciones
o hacerse cargo del mantenimiento si tiene tiempo, habilidades e interés.
Tenga cuidado con el mantenimiento del software sin upstream
ya que toda la carga de mantener el código base
y las tareas de empaquetado recaen sobre usted.
ISi el upstream no responde y muchas distribuciones se desvían significativamente
podría ser una oportunidad para una bifurcación de distribución cruzada.
(Similar a XFree86 y Xorg).
2 days ago
User avatar None

String added in the repository

  1. fedora-docs-l10n/package-maintainers
  2. master/pages/Staying_Close_to_Upstream_Projects
  3. Spanish
*Unmaintained Or Unresponsive Upstream Projects*:
In cases where upstream projects are either unmaintained or unresponsive,
it might be acceptable to patch the software.
If upstream is unmaintained,
you might want to consider sharing patches with other distributions
or taking over maintenance
if you have the time, skills, and interest.
Be wary of maintaining software with no upstream
since all the burden of maintaining the codebase
as well as packaging issues are with you.
If upstream is unresponsive and many distributions are deviating significantly,
it might be a opportunity for a cross distribution fork
(Similar to XFree86 and Xorg).
 
2 weeks ago
Browse all string changes

Things to check

Mismatching line breaks

Number of new lines in translation does not match source

Reset

Glossary

English Spanish
No related strings found in the glossary.

String information

Source string description
type: Plain text
Flags
no-wrap, placeholders:r"`[\w\d -_<>(){}\[\]@$;.\*+=]*`":r"(link:)?https?://[\w\d\-_#?&%=\./]*":r"xref:[\w\d\-_/]*\.adoc(#[\w\d\-_/]*)?"
Source string location
./pages/Staying_Close_to_Upstream_Projects.adoc:272
String age
2 weeks ago
Last updated
2 days ago
Source string age
5 months ago
Translation file
po/es/master/pages/Staying_Close_to_Upstream_Projects.po, string 37