Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Produce packaging guidelines #29563

Open
brson opened this issue Nov 4, 2015 · 7 comments
Open

Produce packaging guidelines #29563

brson opened this issue Nov 4, 2015 · 7 comments
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. P-low Low priority T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue.

Comments

@brson
Copy link
Contributor

brson commented Nov 4, 2015

Summarize what we've learned into some general guidelines for packagers.

Potential topics:

  • Maintaining independently-bootstrapped Rust compilers.
  • Packaging Cargo libraries / applications
  • Generating offline docs

re https://internals.rust-lang.org/t/perfecting-rust-packaging-the-plan/2767

@brson brson added the A-docs label Nov 4, 2015
@steveklabnik
Copy link
Member

At what point are we far enough along that I should start work on this?

@steveklabnik
Copy link
Member

@brson ping! Have we gotten far enough for me to write these docs yet, and how would I go about finding that information?

@brson
Copy link
Contributor Author

brson commented Aug 2, 2016

We could probably produce some guidelines now. But it would take some investigation to figure out both what packaging-related features we're providing and what packagers are actually doing in practice, and to make sense of it. It's all pretty fuzzy to me still.

I could probably spend a day collecting notes together, then bounce them off our packagers to see if they make sense. Low priority still.

@oconnor663
Copy link
Contributor

Lots of packaging discussion at https://internals.rust-lang.org/t/beta-testing-rustup-rs/3316/188

More Arch Linux specific discussion at https://aur.archlinux.org/packages/rustup/?comments=all

@cuviper
Copy link
Member

cuviper commented Feb 3, 2017

I was just asking @brson for a judgement whether it would be kosher for distros to patch 1.15.0 with #39466, changing a public interface. He indicated discomfort. This particular point is moot if there's going to be a 1.15.1 point release, but there's a larger question here.

What would the Rust Project find acceptable for downstream builders to change? I'd expect general bug fixing to be allowable, but changing a public interface gets questionable, I agree. Do we need to say anything more than that?

Interface questions could also come up if there's ever a separate compiler implemented, say gcc-rust.

Of course, the license permits pretty much any change you like, but maybe there's some trademark muscle to flex behind this policy, if needed. Or maybe you just grumble about out-of-spec implementations.

@steveklabnik steveklabnik added the A-docs Area: Documentation for any part of the project, including the compiler, standard library, and tools label Mar 10, 2017
@steveklabnik steveklabnik added the T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. label May 24, 2017
@steveklabnik
Copy link
Member

Triage: tagging as T-infra as well; docs team is happy to help here, but we'd need you all to get a rough draft together.

@Mark-Simulacrum Mark-Simulacrum added the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Jul 24, 2017
@steveklabnik steveklabnik added the P-low Low priority label Aug 30, 2017
@steveklabnik
Copy link
Member

tagging as p-low, @rust-lang/infra , let the docs team know when you want to collaborate on this

@steveklabnik steveklabnik removed the A-docs Area: Documentation for any part of the project, including the compiler, standard library, and tools label Jan 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. P-low Low priority T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants