Skip to content
This repository has been archived by the owner on May 20, 2020. It is now read-only.

What will become of the 215 issues marked A-rustdoc in the rust-lang/rust repo? Is the intent of this project to obviate all of them? #204

Open
bstrie opened this issue Oct 31, 2017 · 2 comments
Labels

Comments

@bstrie
Copy link

bstrie commented Oct 31, 2017

A quite large proportion of the issues on the official Rust repo are for rustdoc: bugs, suggestions, and feature requests. Is the intent of this tool to be a perfectly-compatible, drop-in, bug-for-bug replacement of its precursor? If not, has there been any attempt to sift through the open issues and pick out the requested enhancements and design them into the tool from the ground-up?

https://github.com/rust-lang/rust/labels/A-rustdoc

@mgattozzi
Copy link
Contributor

I think there's a few ways to sift through them (and I don't think any of us have yet) and tag them:

  1. Bugs - If it's a bug it's for the old rustdoc and once it gets replace these can be closed
  2. Suggestions - If they've been implemented in the new one they can be closed otherwise best to keep open
  3. Feature Requests - In much the same way as suggestions it depends on if they're implemented along the way to feature parity or not.

I don't think the intent is to be a complete bug-for-bug replacement. I think it's just to get this version looking and acting the same at least. This might mean we keep some of the same bugs somehow or inadvertently fixing them.

The main thing here is that the categorization of all the above issues depends on this rustdoc getting to feature parity which is the first goal. It may subsume or close issues in the process. At this point no one has gone through to pick what would be good to include.

@steveklabnik
Copy link
Owner

We're very far off from being able to even consider these things. It's not clear if, once this is good enough, it will go back into the Rust repo, or if we'll always keep it separate and say, move it into the rust-lang org. It's not 100% clear if we intend to make the UI an exact copy or not.

has there been any attempt to sift through the open issues and pick out the requested enhancements and design them into the tool from the ground-up?

Only to some degree; I'm familiar with all of those bugs, so they're on my mind, but at the same time, we're not yet at the stage where we can even work on implementing that stuff. Many of them aren't "from the ground up" things, or at least, not with the implementation strategy we've planned; that is, many of them are front-end requests, and we've mostly been working on getting the backend solid.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants