2015-04-07.md

Agenda 4/7/2015

• Policy/mechanism for targeting PR's to beta vs master, now vs future
• How many past releases will we support?
• Change abs to return an unsigned value (aturon) rust-lang/rfcs#1017 )
• Stabilization around allocation, and unsafe code in general (aturon)
• move docs out of tree? (nrc)
• rustdoc and facade crates (acrichto)
• wiki (nmatsakis)

Attending

steveklabnik, nmatsakis, nrc, pnkfelix, brson, huon, acrichto, pcwalton, aturon

Status

• brson: rustup, 1.0 issues, party planning
• pnkfelix: 1.0 issues, nonzeroing drop
• steveklabnik: book TOC
• nrc: Self:: DST coercions, rustc perf measurement
• nmatsakis: 1.0 issues
• acrichto: burning down rustdoc bugs

Policy for PRs targeting beta vs master

• pnkfelix: Two issues: short and long term. In the short term, might make sense to do some series of direct merges from master -> beta (one - three times). But what do we do beyond that? I've heard talk of cherry picking onto beta, etc. Wanted to get the conversation started.
• steveklabnik: Important to clarify 1.0 beta versus after 1.0. I would like to see Homu doing this work for us. Want to annotate PRs and have them automatically cherry-picked.
• nmatsakis: Concrete proposal: we do two merges from master to beta, this friday and next. After that, we cherry pick individual PRs. For the time being, we tag them with a label (or perhaps the subject line) if they need to go into 1.0
• nmatsakis: Going forward, we'd do cherry-picking only.
• nmatsakis: That should balance the specialness of 1.0 with the desire to get onto the train model.
• brson: How do we want to tag PRs for the beta branch? E.g., we could have a tag "beta" that goes on a PR.
• nrc: I think that's the best option on github.
• steveklabnik: Pre-automation, that makes sense. Eventually we want r+ beta
• acrichto: One downside is that you don't receive notifcations. Unless you're actively looking at the PR body, you could miss it. I would be fine with [beta] in the PR title
• nrc: We need a distinction between request for beta and approved for beta. Should be part of review, or perhaps an additional process.
• brson: Could do it as part of triage.
• nmatsakis: I feel like when you're reviewing, it's reasonably clear. I guess that's how triage works now, where you can now triage directly onto a milestone. Could we use milestones?
• acrichto: Need to require the PR to be merged into beta before master.
• pnkfelix: Are we assuming people are going to open PRs targeting beta?
• steveklabnik: Usually both, right?
• nrc: But the PRs are different.
• brson: Seems like the destination is always master, then cherry pick onto beta as secondary.
• nrc: Should we submit two PRs?
• brson: I don't think we want to put the burden on contributors.
• nmatsakis: Agreed, we need to do this work.
• nrc: I think it should be rare for non-core contributors to submit beta-destined patches anyway.
• pnkfelix: Maybe offtopic, but I would consider e.g. adding more test cases to beta.
• nmatsakis: It's not clear what we want to backport. How far back to support old releases? Security fixes?
• steveklabnik: This recently came up with Ember, where they've never supported old releases. The proposal was to label a release every so often as LTS.
• nmatsakis: Yes, makes sense, but we're too young.
• steveklabnik: Yeah, we can just be clear that we aren't doing that yet and will do in the future.
• nrc: I don't think we should make any promises there until we're ready to execute.
• nmastsakis: Ok, so we're always backporting to beta, never prior.
• nrc: Or maybe backport to current release, chemspill-style?
• nmatsakis: Sure, should be rare.
• brson: Ok, so what's the process here?
• nmatsakis: People can make a beta backport request. When you review, you triage it to beta, or nominated if you're not sure.
• brson: And we just have to make sure these get incorporated before putting out a new beta.
• pnkfelix: So we cherry pick, and don't use any of bors infrastructure? When does testing happen?
• brson: I think the way we test is by pushing directly to auto, then the bot will build it. Once it passes, then you can fast-forward beta. There may need to be a beta marshall for the next cycle.
• acrichto: Why not push directly to beta? The bots will run the tests.
• brson: Could do that, and then do the dist build.
• nmatsakis: Can we adapt Homu?
• acrichto: I think it's pretty simple. If we can give a clear feature request, we can probably get it done. There's already try support, so I think the infrastructure is there.
• nmatsakis: You can specify the target branch when you open a PR, so if that was used...
• nrc: You'd need a second PR.
• nmatsakis: I'd prefer to get notification from Homu rather than trying to check tests manually.
• nrc: So the objection to two PRs was that it might be too many steps to ask non-core contribs to do.
• brson: The implication is that a core contrib would open the second PR if needed; we'll take care of that work.
• nrc: Which PR do we do the tagging on? Do they cross-ref?
• nmatsakis: Seems like the beta PR references the other. Cite the PR in your commit message, and then we can collect a list of PRs that should have been backported, and look at the history of the beta branch and diff the results.
• brson: This is getting complicated. Maybe we should do the simpler option?
• nmatsakis: What's the difference, just the automation?
• brson: Homu runs through integration before merging. Before the dist test would take regression.
• acrichto: Long-term, we'd schedule a beta build nightly, abort if there aren't any changes. Just ahve to make sure to land the PR before that kicks off.
• aturon: Does someone want to write up a concrete proposal and post to discuss?
• steveklabnik: I'll do it!
• nmatsakis: Check with barosl.

Change abs to return unsigned

rust-lang/rfcs#1017

• aturon: RFC 1017 -- short rfc, would be a late-breaking change, didn't quite get it done before beta release
• aturon: sort of a continuation of the overflow changes. abs returns a signed integer when applied to a signed integer. Proposal is to return unsigned instead. INT_MIN is a hazard.
• aturon: wanted to see whether this is something we want to push, since we'd have to do it
• pcwalton: it's not what i'd expect, speaking as a gfx programmer. How would it interact with generics?
• acrichto: well, we don't have generic traits, but it would make it harder
• pnkfelix: it'd need an assoc type for the unsigned variant
• aturon: yes
• pnkfelix: what we talking about? the inherent method?
• aturon: yes
• pcwalton: if it's purely concrete code we're talking about it's prob harmless
• pcwalton: still seems weird
• brson: wondering why it took 5 years to decide if this is a problem?
• pcwalton: do any other languages do it?
• pnkfelix: the corner case doesn't come up very often
• pcwalton: what is the specific bug?
• acrichto: INT_MIN.abs() == INT_MIN
• acrichto: imo we have a budget for breaking changes we can make right now
• acrichto: don't want to spend it on this
• pcwalton: if this prevents a bug in the real world...
• nmatsakis: I have had a bug due to this but I agree it's rare
• brson: what is the workaround to account for int?
• aturon: test and branch
• aturon: in terms of why it's coming up now -- it's a consequence of the overflow changes
• pnkfelix: there is a more conservative approach we can take -- panic if overflow checking is turned on
• nrc: benefit is not really the INT_MIN case, benefit is that you don't have to write abs(foo) as u32, since that's annoyingly redundant
• pcwalton: but when I use abs, I usually want the signed result
• nmatsakis: most code that uses abs in practice probably uses floats
• aturon: author also mentions that firefox does not use abs from the C library but prefers another version that uses unsigned results
• pcwalton: many of the security vulnerabilites
• huon: can we test this against crates.io
• brson: yes if someone writes a patch; is that worth doing?
• nmatsakis: it is hard to get too worked up over it
• aturon: seems like it's not over the bar for a post-beta change
• nmatsakis: we can always make uabs and maybe even deprecate abs if we really wanted
• pcwalton: probably wouldn't want to deprecate for consistency with floats

rustdoc and facade crates

• acrichto: We have 3 architectural problems. When you search on the std docs, you get results from libcore, liballoc, etc. Also, when I crate docs for an external crate that uses Vec, it will link to libcollections, not libstd. Finally, src links cannot be correctly generated unless the doc for the crate has been built. So when you click src on Arc in std, it redirects to liballoc for the src.
• acrichto: These three issues are standing in the way of just not generating the facade docs.
• acrichto: This is important for first impressions of Rust. You shouldn't have to know about the facade when you're first working on Rust.
• acrichto: Error messages would fix the linking problem. We might be able to fix the search problem in an ad hoc way, we might be able to fix the source problem in some other way.
• nmatsakis: Error messages? IN the compiler?
• acrichto: Yeah, type error messages will mention facade crates. If we have knowledge about the canonical location for error messages, we could use it in rustdoc also
• nmatsakis: You're saying we could have a common helper.
• brson: Can we just add an annotation to indicate the canonical location?
• acrichto: Could work... We'd have to do it for every single type.
• brson: Or maybe on the re-export?
• acrichto: rustdoc needs it at the source. When you link to an Option, it knows that it's libcore; it doesn't know that it's in std.
• nmatsakis: We could build up a map that we consult for def id redirection.
• acrichto: If we did that, I think we can fix the search results as well. That just leaves source links. At some point, we can just link to github.
• pcwalton: The right way to do this is bread crumbs in the compiler. clang does this. In the typechecker, they store exactly how the typedefs are made, so they can canonicalize automatically; they prefer the typedef when possible.
• nmatsakis: We used to do something like that, we could do it better now. It's somewhat independent. We don't even want to mention the facade right now.
• steveklabnik: It'd be nice to do this witout src annotations, so that external crates can use it too.
• nmatsakis: pub use is pretty common, that's a good point.
• acrichto: If it's within a single crate, rustdoc already does a good job; but not cross-crate.
• nmatsakis: We can add something hacky for std for now, then generalize later on.
• acrichto: We have a sidebar on the docs saying what crates are there. Should that just say "std"?
• nmatsakis: Sounds good.
• acrichto: You'd have to go to nightly to get docs on e.g. libcollections
• nrc: Is std meant to be the only public crate?
• acrichto: Yes.
• brson: Another thing: I saw a public re-export of an __foo stable thing!
• acrichto: Yep. Lemme know where it is, I'll try to deal with it.
• pnkfelix: I'm confused now. Are we only going to render stable items?
• acrichto: That's an interesting question -- what do we do with stability? We have some unstable crates, but then we also have crates like std that are a mixture. In theory, you should only see the stable docs, you shoudl have to opt in to unstable ones. But I want to come back to that later.
• aturon: Do we want to commit to hiding the facade for 1.0?
• acrichto: I don't think so; bigger fish to fry.
• brson: It's not clear that we want to hide it.
• nrc: In the long run I don't think it makes sense to hide this; it exists.
• acrichto: But on the other hand, when you search for Option, you see a bunch of results, which can be confusing. I think we can make improvements with minor fixes.
• nrc: For now, that makes sense. But I think we'll want to reverse it later.
• brson: Right, eventually crates under the facade will be stable.
• aturon: std is supposed to be an abstraction, though; I think it's valid to completely hide the facade except for "advanced" cases.
• nmatsakis: I agree. But, it doesn't seem like the highest priority.

wiki

• nmatsakis: We dropped the wiki a little while back, but I think there are a few things that really belong on a wiki. I'm wondering if we made the right call.
• nmatsakis: e.g. list of publications related to Rust. Should that really live in the repo? Similarly projects using Rust.
• steveklabnik: I wanted to expose use cases by removing the wiki.
• nmatsakis: Oh yeah, having a more targeted wiki could make sense.
• brson: I've had a few pages I've been sad to lose. Friend of the tree, etc.
• steveklabnik: Some of this could go in the book.
• pnkfelix: The getting started page...
• brson: I think the wiki did well there; it covered low-priority platforms, for example.
• aturon: We could put some of this on the web page. Scala has a publication list, for example.
• pnkfelix: Doesn't feel as lightweight as the wiki for making changes, though.
• brson: Maybe there's room for a separate community wiki? For example, reddit supports wikis.
• nrc: There is a visibility issue, though. I suppose we could just link to it from the Rust web site.
• brson: The getting started guide, for example, has a lot of churn. That's one reason not to put it into the docs.
• nrc: To me, there's a lot of developer-oriented stuff that might not want to go into the rustdocs. For example, using rustc without Cargo. Not intended for newcomers, experts only. Separate set of docs, or outside the docs?
• steveklabnik: We talked before about a doc folder with markdown. Github will render, we can link from the README.

move docs out of tree

• nrc: I was wondering about moving the docs out of tree. Before, with the tests etc, that seemed problematic. But now that we're stable, it seems more feasible.
• brson: Still need dist automation. It's not a hard problem, but it is work.
• steveklabnik: Not sure what the gain is.
• nrc: Less churn in the main repo. Less email/notifications. Less infrastructure use (testing). Another benefit is barrier to entry. New contribs can make minor fixes to docs. But downloading a full repo might be off-putting.
• steveklabnik: WIth a small fix, you can just click edit.
• pnkfelix: I've definitely had bugs that were caught by doctests.
• nmatsakis: Presumably we'd still run the doc tests.
• nrc: But with no breaking changes, should be less of an issue.
• steveklabnik: The API docs have to stay. Moving "the docs" out really just means "the book". Most bugs I get are for API docs, not the book.
• brson: Moving the book out would allow rustbook to move out as well.
• nrc: Yeah, I was thinking of the book only.
• brson: I think the automation questions are hard enough that this isn't worth doing yet.
• steveklabnik: I'm also hoping for less churn in the book after 1.0...