Upstream: Difference between revisions
Jump to navigation
Jump to search
mNo edit summary |
mNo edit summary |
||
| Line 6: | Line 6: | ||
'''In networking at service level''', 'upstream servers' | '''In networking ''at service level'' ''', this can indicate a similar relation -- e.g. | ||
: say, nginx saying 'upstream servers' tends to mean 'the thing we're sitting in front' | 'upstream servers' often suggests we are (reverse-)proxying requests to them. | ||
: your ISP's DNS server is upstream relative to your modem's DNS server | : say, nginx saying 'upstream servers' tends to mean 'the thing we're sitting in front of' | ||
: your ISP's DNS server is upstream, relative to your modem's DNS server (if any) | |||
https://en.wikipedia.org/wiki/Upstream_server | https://en.wikipedia.org/wiki/Upstream_server | ||
| Line 18: | Line 18: | ||
Upsteam are the originators of the code, | Upsteam are the originators of the code, | ||
downstream are people that use a packaged or derived version | downstream are people that use a packaged version, or derived version. | ||
Downsteam may tweak it for easier consumption -- but e.g. tends to keep in mind which edits are made, | |||
and keep them minimal where possible, | |||
so that upstream changes are dealt with sensibly. | |||
The term 'upstream' often comes up in support tickets. | The term 'upstream' often comes up in support tickets. | ||
For example, when a ubuntu package is broken, you may find a support ticket | |||
: yes, we could patch it in our derived version as soon as possible | For example, when a ubuntu package is broken, you may find a support ticket discussion that ends with | ||
: | ''"has been fixed upstream, please wait for the next release,"'', | ||
:: it keeps downstream's | which is a way of saying | ||
:: avoids us duplicating work that is ''better'' done upstream, | : yes, we ''could'' patch it in our derived version as soon as possible | ||
: but we won't unless it's security-critical, | |||
: because upstream is also fixing it, and it's easier to trickle down to the next version of the package | |||
:: it keeps downstream's changes minimal, and less likely to break over time | |||
:: avoids us duplicating work that is ''better'' done upstream may conflict, may cause branches, merges, forks | |||
As a side effect, upstream may have its own logic about not making functional changes ([[semantic versioning]] and all), | |||
so features are sometimes delayed by downstream just saying it's waiting for upstream's next major release. | |||
It also makes certain policies | It also makes certain policies shorter to explain, | ||
such as "we update to newer upstream releases without concern for backwards compatibility" | |||
{{comment|(a.k.a. "we mostly just shove the thing in your package manager, the rest is your problem")}}, | |||
and this may help you estimate the likelinss that the downstream developers will write patches for continuity. | |||
https://en.wikipedia.org/wiki/Upstream_(software_development) | https://en.wikipedia.org/wiki/Upstream_(software_development) | ||
--> | --> | ||