Поток разработки и взаимодействие с разработчиками исходного кода
Upstream (software development)
Upstream в разработке ПО: что это такое? Объяснение понятия, важность для форков, библиотек и патчей. Вклад в оригинальный проект и получение обновлений.
Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Введение
Концепция в разработке программного обеспечения
Concept in software development
В разработке программного обеспечения, когда программное обеспечение было разветвлено или использует цепочку библиотек/зависимостей, термин "upstream" (вверх по течению) относится к проблеме, возникающей в программном обеспечении, связанном с этой цепочкой. Он указывает направление к оригинальным авторам или сопровождающим программное обеспечение. Обычно используется в контексте версии, ошибки или исправления. Разработка "upstream" позволяет другим дистрибутивам воспользоваться ею, когда они принимают будущий релиз или включают недавние (или все) исправления "upstream". В свою очередь, оригинальные авторы (поддерживающие "upstream") могут получить пользу от вкладов, поступающих из кастомизированных дистрибутивов, если их пользователи отправляют исправления "upstream". Этот термин также относится к ошибкам: ответственность за ошибку считается лежащей "upstream", если она не возникла в результате портирования, модификации или интеграции, выполненных дистрибутивом.
In software development, when software has been forked or uses a chain of libraries/dependencies, upstream refers to an issue that occurs in software related to the chain. It is the direction that is toward the original authors or maintainers of software. It is usually used in the context of a version, a bug, or a patch. Upstream development allows other distributions to benefit from it when they pick up the future release or merge recent (or all) upstream patches. Likewise, the original authors (maintaining upstream) can benefit from contributions that originate from custom distributions, if their users send patches upstream. The term also pertains to bugs; responsibility for a bug is said to lie upstream when it is not caused through the distribution's porting, non upstream modification or integration efforts.
Примеры
Патч, отправленный разработчикам оригинального проекта (upstream), предлагается авторам или сопровождающим программного обеспечения. Если патч принимается, авторы или сопровождающие включат его в свою версию программы, либо немедленно, либо в одном из будущих релизов. В случае отклонения, автор патча должен будет самостоятельно поддерживать свою версию программного обеспечения. Upstream-репозиторий или дистрибутив исходного кода может представлять собой версию, отмеченную релизом, для которой исходный код был специально упакован, конкретный коммит или ветку master (термин, обозначающий последний коммит). Пользовательские дистрибутивы (например, форки) могут не получать исправления ошибок и улучшения (развитие проекта, связанное с оригинальными авторами и upstream) из-за отсутствия слияния (всех) upstream-патчей. В таких случаях пользовательский дистрибутив может быть даже адаптирован к специфическим потребностям и требованиям его пользователей и сопровождающих. Подобное часто встречается и с зависимостями (пакетами поставщиков), когда пользователь ограничивается базовой версией и продолжает её использовать, со временем накапливая множество (произвольных) модификаций или нестандартных способов применения в своей среде. В результате слияние последних upstream-патчей в пользовательский дистрибутив становится невозможным без значительных усилий по обеспечению совместимости патчей и функциональности, а также для предотвращения дублирования исправлений ошибок, которые были решены пользователем самостоятельно (и своим способом), в то время как upstream также имеет патч для этой ошибки. Многие пользователи пользовательских дистрибутивов всё же выборочно применяют и объединяют критические upstream-патчи, особенно те, что связаны с уязвимостями в системе безопасности.
A patch sent upstream is offered to the original authors or maintainers of the software. If accepted, the authors or maintainers will include the patch in their software, either immediately or in a future release. If rejected, the person who submitted the patch will have to maintain his or her own distribution of the author's software. Upstream repository or source code distribution version, which can either be a version tagged release for which the source code has specifically been packaged, a specific commit, or master (jargon for latest commit). Where custom distributions (such as forks) may have missed out on bugfixes and improvements (maturing of the project tied to the original authors, upstream) as a result of not merging (all) upstream patches. In such cases, the custom distribution may even have been adapted to suit the specific needs and requirements of those using or maintaining it. This is also often seen with dependencies (vendor packages), where the taker just settles with a base version once and tends to stick with it, over time accumulating so many (arbitrary) modifications or non standard uses in their environment that merging the latest upstream patches into their custom distribution won't be possible without major additional work for patch and feature compatibility, and avoiding duplicate patches of bugs that they resolved by themselves (and in their own way) while upstream also has a patch for it. A lot of custom distribution users would still cherry pick and merge critical upstream patches (such as security vulnerability related).