Brson's "someday" list


Updating with:


Updated with:




Updated op with these. A lot are pretty opaque. Sorry about that.


  • write security roadmap
  • write release qa checklist
  • investigate rustup disk usage during transactions
  • change rustup to panic=abort
  • write rust packaging guidelines
  • get rustup working via powershell one-liner
  • add cargo-template quickstart instructions to error-chain docs
  • set up static linking for msvc rustc
  • fix rustup windows dojob issue (make cargo and rustup use the same dojob code)
  • simple crates in need - extract these from rustup/cargo and share
    • copy_dir
    • remove_dir_all
    • dojob
    • flock
    • symlink_dir
    • homedir
  • implement the update framework



What’s this one?


Sounds like you should be able to just run cargo template quickstart my-new-project and get a project setup to use error-chain.


Neat. Should it work in conjunction with this PR for cargo or some other way?


I believe my intent was to make compatible with, in anticipation of compatibility with your cargo PR in the future.


Templating was merged into Cargo yesterday.

The following project can be used as a quickstart template (I made a PR to use {{name}} and {{author}} templates:


Thanks @ehiggs!


@ehiggs What is the cargo command to instantiate the error-chain directly from the error-chain repo ( I’d like the error-chain docs to say something like

To get started run:

$ cargo template whatever

(Obviously fill in with the correct syntax)


$ cargo new --template whatever

Currently there is a bug in that particular template where the name and author aren’t actually templated but I have a PR to fix it.


Here’s some commentary about the ‘simple crates’:

16:32 simple crates - there are a number of unbelievably common functions i end up reimplementing a lot 16:32 and poorly 16:33 copy_dir is just a recursive directory copy. not sure if there’s a good crate for this yet 16:34 sometimes one needs to do a copy but ignoring dotfiles. i open code this with walk_dir 16:34 but there should be a common copy_dir that covers most cases and just works 16:34 remove_dir_all is broken in std on windows 16:34 so people always reimplement in 16:34 *it 16:35 while it should be fixed in std, in the meantime somebody should just publish a working version 16:35 dojob is a common routine that cargo, rustbuild and rustup use to create process groups on Windows for killing multiple processes 16:35 but they all implement it diferently and some are missing fixes 16:36 symlink_dir would be a crate that creates symlinks to directories correctly on windows, using directory junctions 16:37 homedir would be an implementation of std::env::home that uses cargo/rustup’s definition. I consider std incorrect when it considers HOME on Windows.


I’ve updated the list with:


  • document interfaces that are not-really stable
  • port cargobomb to windows
  • add stdx ci testing
  • install more things in cargobomb docker container


  • run custom shootout server with additional nightly benchmarks
  • write hello.exe size test
  • switch default rustup to -gnu
  • do analysis of servo crash fixes vs firefox crash fixes
  • propose proprietary Rust testing service


why proprietary?


It’s not the service itself that is proprietary, but a service for regression testing proprietary Rust projects, to give us visibility into the ecosystem where we are lacking it. It would be a formal structure for setting up NDAs and compensation for running cargobomb and similar future efforts on closed-source projects.


As a once and future (hopefully with rust) "Enterprise Software Developer"™, I think this could go a long way towards reassuring companies that they could rely on rust for their development future.


@brson I would like to help with

  • weekly compiler-perf report;

What does it actually entail? Hope explaining what it entails doesn’t take as long as actually doing it. :slight_smile:

From the single line, I assume it has to do with measuring performance of the compiler over its development history. Sounds related to continuous integration/testing/benchmarking. Would this use gperf? Which benchmarks would you use to measure this?


@pmatos The main idea is just to get information about the performance of the Rust compiler in front of people on a regular basis, to build a sense of accountability. At the time I would have said to examine to extract a sensible story about what happened last week, and just write it up in a consistent way, with key metrics. At the moment though perf.rlo is not working…


Templates was pulled out pending an RFC. The feedback in a pre-RFC thread suggests that people don’t want it in cargo but would rather an external cargo tool like clippy.


I updated the op with the following:


  • update platform support page with richer info about which are tested
  • teach cargobomb to print rustc version in every run
  • fix skeptic linkage issue
  • solicit cargobomb help
  • upload libz blitz videos to youtube
  • create 1.0 crate scoreboard
  • conduct research project on structuring projects for contribution