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

Comments

Projects
None yet
5 participants
@brson
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

This comment has been minimized.

Show comment
Hide comment
@steveklabnik

steveklabnik Jan 26, 2016

Member

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

Member

steveklabnik commented Jan 26, 2016

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

@steveklabnik

This comment has been minimized.

Show comment
Hide comment
@steveklabnik

steveklabnik Mar 9, 2016

Member

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

Member

steveklabnik commented Mar 9, 2016

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

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Aug 2, 2016

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
Contributor

oconnor663 commented Aug 31, 2016

@cuviper

This comment has been minimized.

Show comment
Hide comment
@cuviper

cuviper Feb 3, 2017

Member

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.

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 T-doc label Mar 10, 2017

@steveklabnik steveklabnik removed the A-docs label Mar 24, 2017

@steveklabnik

This comment has been minimized.

Show comment
Hide comment
@steveklabnik

steveklabnik May 24, 2017

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.

Member

steveklabnik commented May 24, 2017

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.

@steveklabnik

This comment has been minimized.

Show comment
Hide comment
@steveklabnik

steveklabnik Aug 30, 2017

Member

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

Member

steveklabnik commented Aug 30, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment