Zen

Translation

English type: Plain text
*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.
452/3660 · 366

Sign in to save the translation.

English Spanish Actions
*Patches*: Patches are the most common and obvious type of change from upstream.
Patches might be written by the package maintainer,
cherry picked or backported from upstream
or picked from other distributions.
*Parches*: Los parches son el más común y obvio tipo de cambio del upstream.
Los parches pueden estar escritos por el mantenedor del paquete,
seleccionados o respaldados desde el upstream
o seleccionados de otras distribuciones.
*Running sed or equivalent on a spec file*:
While this change is less obvious,
it should be considered functionally equivalent to a patch
for the purposes of this guide.
Also a patch is preferable
because running sed can sometimes change the software in unintended ways
especially when the package maintainer is pushing a new upstream release as an update
and such changes might not be obvious compared to a failed patch.
*Ejecutando sed o equivalente en un archivo de especificaciones*:
Aunque este cambio es menos obvio,
debería ser considerado equivalente a un parche
para los propósitos de esta guía.
Un parche es también preferible
porque al ejecutar sed puede cambiar, algunas veces, el software de forma no pretendida
especialmente cuando el mantenedor del paquete está impulsando una nueva versión upstream como una actualización
y dichos cambios pueden no ser obvios en comparación con un parche fallido.
Desktop files, systemd unit files, etc. are sometimes added as *additional sources*: If you do this as a package maintainer, you need to notify upstream and ideally get them included as part of the upstream source. Maintaining them separately often involves additional maintenance.
Archivos de escritorio, archivos de unidad systemd, etc. se añaden algunas veces como *fuentes adicionales*: Si usted hace esto como mantenedor del paquete, necesita notificarlo upstream e idealmente incluirlos como parte de la fuente upstream. Mantenerlos por separado a menudo implica un mantenimiento adicional.
*Configuration options*:
For instance, if a particular upstream software allows both MySQL and Postgres as a database backend,
other distributions might have picked Postgres
and Fedora package might be configured to use the MySQL backend by default instead.
If upstream or other distributions are favoring one of the options over the others,
talk to them,
find out why
and rely on well tested and consistent options as much as possible.
*Opciones de configuración*:
Por ejemplo, si un software upstream concreto acepta tanto MySQL como Postgres como backend de base de datos,
es posible que otras distribuciones hayan elegido Postgres
y el paquete Fedora podría estar configurado para usar el backend MySQL de forma predeterminada en su lugar.
Si upstream u otra distribución está favoreciendo una de las opciones sobre las otras,
hable con ellos,
descubra por qué y
confíe en opciones consistentes y bien probadas tanto como sea posible.
*Underlying libraries and other software components*:
Even without intentional modifications,
software in Fedora can still be different from upstream or other distributions,
due to precise library versions or other software components your package depends on.
For instance, Firefox may expose a sqlite bug,
and Fedora might be the only distribution building that precise version of Firefox
against that specific version of sqlite.
You should talk to upstream and find out whether there are any such known issues,
and search through upstream bug trackers
or other popular distribution bug trackers
to figure out such problems.
*Bibliotecas subyacentes y otros componentes de software*:
Incluso sin modificaciones intencionales,
el software en Fedora puede ser todavía ser diferente del upstream u otras distribuciones,
debido a versiones precisas de la librería u otros componentes de software de que depende el paquete.
Por ejemplo, Firefox puede exponer un error sqlite
y Fedora podría ser la única distribución que construye esa versión específica de Firefox
contra esa versión específica de sqlite.
Debería hablar al upstream y buscar si hay alguna cuestión conocida
y buscar en los rastreadores de errores upstream
u otros rastreadores de errores populares de la distribución
para ver el problema.
*Miscellaneous*:
The above list is not comprehensive.
Even seemingly minor changes like the specific desktop theme or fonts
can exhibit bugs in other software,
or can expose a bug in the theme or font
but only with some specific software.
For instance, LibreOffice might have a problem displaying a list
when using the Adwaita theme and Dejavu font.
When analyzing issues,
make sure you consider the impact of every change
either in Fedora or by users themselves.
*Miscelanéos*:
La lista anterior no es exhaustiva.
Incluso cambios aparentemente menores como el tema o las fuentes específicas del escritorio,
pueden presentar errores en otro software,
o puede exponer un error en el tema o fuente
pero solo con algún software específico.
Por ejemplo, LibreOffice puede tener un problema mostrando un lista
cuando usa el tema Adwaita y la fuente Dejavu.
Cuando se analizan cuestiones,
compruebe considerar el impacto de cada cambio
en Fedora o para los usuarios.
Why push changes upstream?
¿Por qué impulsar los cambios upstream?
*Common Benefit And Reduced Maintenance Burden*:
When Fedora carries patches that are specific to Fedora or deviations from upstream projects,
those patches are not shared by every distribution.
This puts the burden of maintaining those patches on Fedora,
which includes keeping those patches in a functional state
by rewriting or forward-porting them for every upstream release.
This effort can quickly add up to be overwhelming,
while not being in the spirit of sharing the benefits
(as well as the effort in maintaining)
free and open source software.
*Beneficio Común y Carga de Mantenimiento Reducida*:
Cuando Fedora lleva parches que son específicos de Fedora o desviaciones de proyectos upstream,
estos parches no son compartidos por cada distribución.
Esto pone el coste del mantenimiento de esos parches en Fedora,
que incluye el mantener esos parches en un estado funcional
reescribiéndolos o reenviándolos para cada versión upstream.
Este esfuerzo puede rápidamente resultar abrumador,
sin tener el espíritu de compartir los beneficios
(así como el esfuerzo en el mantenimiento)
del software libre y de código abierto.
*Documentation*:
Upstream projects are documented formally
(in the form of man/info pages and longer guides)
and informally in many user forums or mailing lists as answers to user questions.
Deviations from upstream projects can thus confuse end users and upstream developers
when those patches cause changes in behavior that are Fedora specific
and not documented properly,
even where the formal documentation
(such as man pages)
are also patched to describe the changes.
*Documentación*:
Los proyectos upstream están documentados formalmente
(en la forma de páginas de manual/informativas y en guías más largas)
e informalmente en muchos foros de usuarios o listas de correos como respuestas a las preguntas de los usuarios.
Las desviaciones de los proyectos upstream pueden de este modo confundir a los usuarios finales y a los desarrolladores upstream
cuando esos parches pueden cambiar comportamientos que son específicos de Fedora
y no documentados apropiadamente,
aún donde la documentación formal
(como las páginas de manual)
también hayan sido parcheadas para describir los cambios.
*Translations*:
Maintaining translations upstream gains the advantage of established translation communities,
which are most likely more experienced with the project terms.
Downstream projects benefit when using those translations.
In addition, it lifts the burden of hosting,
and of the need to merge often from upstream to downstream and back again.
To make sure translation work continues upstream.
Any string changes that were introduced by patches should be maintained by the downstream community.
*Traducciones*:
El mantenimiento de las traducciones upstream tiene la ventaja de establecer comunidades de traductores,
que probablemente tengan más experiencia con los términos del proyecto.
Los proyectos downstream se benefician cuando utilizan esas traducciones.
Además, elimina la carga de alojamiento
y la necesidad de fusionarse a menudo desde el nivel upstream al downstream y viceversa.
Para garantizar que el trabajo de traducción continúe en sentido upstream.
Cualquier cambio en una cadena que se haya introducido por un parche debería ser mantenido por la comunidad downstream.
*Upstream Acceptance*:
Fedora is downstream of many thousands of software projects.
Much of this software is packaged by maintainers who are not programmers
or lack expertise in the language(s) the software is written in.
In some cases the software has a large and complex codebase
(such as the kernel or Libreoffice)
and the package maintainers might not have the same level of understanding in all areas
compared to subsystem maintainers or upstream developers.
For this and other reasons,
Fedora needs the acceptance of upstream software developers.
These developers may view any significant patches as a fork
or refuse to take bug reports from Fedora users
due to the differences in the codebase.
Fedora as a project strives to be welcoming and cooperative with upstream developers
as much as possible.
We must avoid Fedora specific patches
and any patches that are useful should be sent upstream to these developers
via mailing lists, bug trackers, or direct email.
*Aceptación Upstream*:
Fedora está downstream de muchos miles de proyecto de software.
Mucho de este software está empaquetado por mantenedores que no son programadores
o carecen de experiencia en el lenguaje(s) en el que el software está escrito.
En algunos casos el software tiene una gran y compleja base de código
(como el kernel o Libreoffice)
y los mantenedores del paquete pueden no tener el mismo nivel de conocimiento en todas las áreas
en comparación con los mantenedores de los subsistemas o los desarrolladores upstream.
Por esta y otras razones,
Fedora necesita la aceptación de los desarrolladores de software upstream.
Estos desarrolladores pueden ver cualquier parche importante como un desvío
o negarse a recibir informes de errores de los usuarios de Fedora
debido a las diferencias en el código base.
Fedora como proyecto se esfuerza por ser acogedor y cooperativo con los desarrolladores upstream
tanto como sea posible.
Debemos evitar parches específicos de Fedora
y cualquier parche que sea útil debe enviarse a los desarrolladores
a través de listas de correo, rastreadores de errores o correo electrónico directo.
*Quality Assurance*: Patches that are accepted upstream
are usually reviewed or tested by many people
including developers and testers.
This includes testing by other GNU/Linux distributions.
A deviation from the common codebase used by many
is a potential chance of introducing a regression that is specific to Fedora.
*Control de Calidad*: Los parches que son aceptados upstream
son normalmente revisados o probados por mucha gente
que incluye a desarrolladores y probadores.
Esto incluye su prueba en otras distribuciones de GNU/Linux.
Una desviación del código base común usado por muchos
es una oportunidad potencial de introducir una regresión que es específica a Fedora.
*Security*:
A special case of the "Quality Assurance" issue
is that changes that have surprising security implications
are more likely to be detected by upstream
(who often have deeper knowledge of the program).
*Seguridad:*
Un caso especial de la cuestión de "Garantía de Calidad"
son los cambios que tienen implicaciones de seguridad por sorpresa
tienen más posibilidades de ser detectados upstream
(quien, con frecuencia, tiene un conocimiento más profundo del programa).
*Fast incremental improvements*:
Staying close to upstream versions is helpful
when doing version bumps for updates that bring in new features.
This prevents tedious backporting of only security and bug fixes.
Deviations from upstream can significantly hamper the speed of delivering improvements
from new versions to end users.
However, regressions are to be avoided,
and potential improvements and new features must be carefully assessed
against the risk of harming the users experience.
Refer to xref:fesco::Updates_Policy.adoc[Updates Policy] for more details.
*Mejoras incrementales rápidas:*
Mantenerse cerca de las versiones upstream es útil
cuando se realiza cambio de versión para actualizaciones que incorporan nuevas funciones.
Esto evita vueltas atrás tediosas únicamente de seguridad y correcciones de errores.
Las desviaciones upstream pueden obstaculizar significativamente la velocidad de entrada de mejoras
de las nuevas versiones a los usuarios finales.
Sin embargo, se deben evitar las regresiones
y se deben evaluar cuidadosamente las posibles mejoras y nuevas funciones
frente al riesgo de dañar la experiencia de los usuarios.
Vea más detalles en ref:fesco::Updates_Policy.adoc[Política de Actualizaciones].
*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.
 

Loading…

User avatar vareli

Translation changed

  1. fedora-docs-l10n/package-maintainers
  2. master/pages/Staying_Close_to_Upstream_Projects
  3. Spanish
*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.
2 days ago
User avatar vareli

Translation added

  1. fedora-docs-l10n/package-maintainers
  2. master/pages/Staying_Close_to_Upstream_Projects
  3. Spanish
*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,
ueden 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.
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
*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.
 
2 weeks ago
Browse all string changes

Things to check

Double space

Translation contains double space

Fix string

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:175
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 23