You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What benefit does upstream get by supporting debian packaging workflow?
ohler55/oj#610 this can be quoted as a benefit to upstream when we run tests. When we run tests for native gems, we run them on many architectures and help fix bugs.
Another one is like we switch to newer ruby, rails etc before upstream does. So we test and report problems before they do it for many packages.
Why do you want to run tests? Or why do you want to take github tarballs?
Tests help us during transitions (for example we want to update ruby or rails for all packaged gems in one go). We are happy to take rubygems.org as source if it contains tests.
Why can't you take gems from from rubygems.org instead of creating debs?
I think you should also expand on terminology like "upstream" and "downstream" as in:
This Packaging style guide outlines the recommended best practices for real-world programmers to write code that can be maintained both, upstream and downstream.
I'm relatively certain that the downstream part will confuse some people. :-)
ohler55/oj#610 this can be quoted as a benefit to upstream when we run tests. When we run tests for native gems, we run them on many architectures and help fix bugs.
Another one is like we switch to newer ruby, rails etc before upstream does. So we test and report problems before they do it for many packages.
Tests help us during transitions (for example we want to update ruby or rails for all packaged gems in one go). We are happy to take rubygems.org as source if it contains tests.
celluloid/celluloid#263 (comment)
The text was updated successfully, but these errors were encountered: