Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Кіріспе
Бағдарламалық жасақтаманы әзірлеудегі түсінік
Concept in software development
Бағдарламалық жасақтаманы әзірлеуде, бағдарламалық жасақтама бұтақталған немесе кітапханалар/тәуелділіктер тізбегін пайдаланған кезде, "upstream" – бұл тізбекке қатысты бағдарламалық жасақтамада туындаған мәселені білдіреді. Бұл бағдарламалық жасақтаманың бастапқы авторларына немесе оны қолдаушыларға бағытталған бағыт. Ол әдетте нұсқа, қате немесе түзету туралы сөз болғанда қолданылады. 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 репозиторий немесе бастапқы кодты тарату нұсқасы, бұл бастапқы кодқа арнайы жинақталған нұсқа, нақты бір коммит немесе master (соңғы коммит үшін қолданылатын термин) болуы мүмкін. Әдеттегі таратылымдар (мысалы, бұрандалар) жоғары деңгейдегі түзетулерді біріктірмеу нәтижесінде қателерді түзетулер мен жақсартулардан (жобаның бастапқы авторларға байланысты дамуы, 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).