mozilla :: #rust-infra

17 Oct 2017
00:09aidanhsnot sure, but you can test any possible fix locally with the PR I've just made against the crater repo
00:11aidanhsit's not yet merged as I want to double check it tomorrow, but assuming it's correct it doesn't require you to wait half an hour for a docker image to build now, and you should be able to reproduce the problem quite quickly
00:12aidanhssimulacrum: it might just be a matter of finding the places that run generate-lockfile and fetch, and make them use the appropriate toolchain rather than stable
00:12simulacrumthat seems in theory trivial but also somewhat complicated
00:13aidanhsyou could also hack it on the prod box by making the base toolchain be beta
00:14simulacrumwith a beta vs. stable run instead of stable vs. beta?
00:15simulacrumthis seems like either way we'll run into problems b/c generate-lockfile is going to be run on either beta *or* stable which will mean that one of the two parts fails
00:15aidanhsthe cargo issue says that older versions of cargo will not rewrite lockfiles generated by newer versions
00:18aidanhsI don't think that's what I meant though - crater uses three different toolchains, one to generate lockfiles and fetch (usually stable) and the other two to do the actual build
00:18simulacrumbut will stable work with beta-generated lockfiles?
00:18aidanhs(if you look at the prepare-ex logs for a PR crater run, you can see it using +stable which is either toolchain)
00:19aidanhssimulacrum: yes
00:19simulacrumah, okay
00:19simulacrumthen I see how this can work
07:04kivikakkjust kinda going ham on all the A-readme issues on atm
14:05carols10centshiii i can't make it to the meeting today
14:40carols10centsgithub's having some slowness right now for everyone's info
15:10acrichtoaidanhs: ping
15:17aidanhsacrichto: pong
15:37jlorenzohi there! who can I talk to about packaging the rust compiler?
15:54acrichtojlorenzo: perhaps many! build system issues? unsure how to package things? Looking for prior art?
16:10jlorenzoacrichto: I think it's more "unsure how to package things. Canonical would like to ship rust in a different package than the old .deb. They're looking for contacts to get started. They reached out to our team first, because we're building Firefox to also that new format
16:11acrichtoaha! in that case you may want to ping jistone (cuviper on github) or infinity0
16:11acrichtothey do fedora/debian respectively, I believe
16:11acrichtoI can also try to help out with general questions
16:11acrichto(will be back in a bit)
16:13aidanhsjlorenzo: it's probably worth creating a thread on, I think they're both active on there
16:14aidanhs(if you end up with some particular questions in mind)
16:14jlorenzoaidanhs: acrichto: thanks guys! I'll point them to internals.r-u.o, then.
16:15jlorenzoacrichto: do you mind if I cc you to my email reply?
16:31acrichtojlorenzo: feel free!
16:31jlorenzothank you!
16:49aidanhsmay be 5-10 min late for start of meeting
16:59shepI remembered the meeting today
17:00ericktI'm actually here!!
17:01aturoncouple folks will be absent/late
17:01aturonsimulacrum: you around?
17:02aturonalright, that seems like quorum to me, let's get started!
17:02aturonfirst up, PR tracking sheet
17:03aturondoesn't seem like anything notable there
17:03aturonbors backlog is as good as it's been in the last couple of months
17:03aturon(this is
17:04aturonanybody have notes re: PR triage?
17:04acrichtothat looks like a bit of an upward trend
17:04acrichtosince august
17:04aturonoverall yes
17:04aturonbut it seems largely explained by waiting-on-author
17:05shepWe've been a bit slack on a few times, but the review amount on a given day after some slack wasn't terrible
17:05acrichtoaturon: true, that coul djust be impl period
17:05shepnot sure if that means anything, but was something I noticed
17:05aturonthat's what i was thinking, yeah
17:05aturonin any case waiting-on-author is, to me, the least worrisome state
17:05aturon(it's the one we have least control over, for one)
17:06aturonother concerns here?
17:06aturonso i've been away the last couple of weeks -- anyone want to recap the current spurious failure situation?
17:07aturon(aidanhs has a note in the agenda that two spurious failures were fixed last week)
17:07acrichtokennytm may know best?
17:07simulacrumaturon: Yeah, just a little late
17:07kennytmyep. so firstly the Android SDK HTTPS thing, which was quickly workaround
17:07aidanhswhile im briefly still available, ill note that two spurious failures have been squashed in the last week, kennytm on bad openssl downloads and me on a test intermittent failure
17:08aturonaidanhs++, kennytm++
17:08kennytm - 3 instances of LLDB segfault on macOS at the start of last week, but no longer happens afterwards.
17:08kennytm - 3 hour timeout
17:08kennytm - linker segfault on macOS
17:08kennytm - travis build spuriously canceled
17:08kennytmthat's all the spurious errors i've touched
17:08aidanhs(that message was delayed by 5min, train internet)
17:09simulacrumlinker segfault on OS X should've been fixed by the retries we implemented a while back? hm
17:09acrichtosimulacrum: it faulted in LLVM's build
17:09acrichto(not rustc's)
17:09aturonyeah issue is marked closed
17:09acrichtoso aidanhs also did analysis of log times
17:09acrichtoand we're getting hit *real bad* with retries from travis
17:09kennytmmaybe the upgrade to xcode8.3 will change the behavior of the macs
17:09simulacrumcould always put up a shim over cc like we do over rustc if this reoccurs
17:09acrichtomost builds are taking far longer than their cycle time
17:10simulacrum2x as long I think?
17:10acrichtotravis is... basically not working on it it appears
17:10simulacrum(at least)
17:10acrichtoat least yes
17:10aturonacrichto: is this again for macs?
17:10acrichtoI wish
17:10acrichtounfortunately for linux and macs
17:10acrichtoany x on 2 or greater means that our builds are 2x longer or more
17:11simulacrum(which is.. all of them, I think
17:11acrichtoclearly showing the problem got way worse in september
17:11acrichtoand isn't improving
17:11aturonoh wow
17:11acrichtotravis has "informed their engineering team" as of a few days ago
17:11simulacrumacrichto: as I read it, any x on 1 or higher is bad -- these are all "redundant"
17:11acrichtowe've been talking to travis for ~2 months about this
17:11acrichtosimulacrum: correct yeah
17:11acrichtothere's also
17:12simulacrumy = 2 means 3x as long
17:12acrichtowhere you can see how the build times got wildly variable in september
17:12aturongood lord
17:12acrichtoafaik we have had little-to-no regressions in our own build
17:12aturoni assume as usual this is "our hands our tied" on the Travis front
17:12acrichtoI believe everything *should* be around 2 hours ish
17:12acrichtofwiw I've been actively investigating circleci
17:12aturonlet's circle back to *this* particular front when we talk roadmap a bit later
17:13acrichtook yeah
17:13acrichtothat's fine
17:13aturonkennytm: do you think any of the spurious failures you logged are worth looking at this week? it seems like probably the Travis situation dominates everything
17:13kennytmaturon: all are minor except the android https one
17:14aturonok cool
17:14aturonso let's start in on the agenda, and we'll come back to Travis later
17:14aturonworking from
17:14aturonfirst-up: the s3 migration caused some unexpected issues
17:15aturonTL;DR: Servo builds were relying on various s3 artifacts that we considered "private"
17:16aturonthis is largely due to miscommunications between the Rust and Servo teams (and a lot of the relevant stuff predates the creation of this team, even)
17:16aturonthat said, I think there's one very important lesson here
17:16shep(aside: I don't know what an "alt" build is, where can I find more info?)
17:16aturonshep: it's one with LLVM asserts disabled
17:16simulacrumshep: .travis.yml, but the gist is normal build w/o LLVM asserts
17:17aturonthe key lesson: before permanently deleting or changing *any* public-facing infra, we need to announce our intent
17:17aturoneven if we consider the infra "de facto" private
17:17aturonif it can be publicly reached, there's a risk it's being used, and we should broadcast our plans beforehand
17:18simulacrumIt's possibly worth asking: perf.rlo's data and backend are in flux constantly, and I change those somewhat often -- is that something we should message out?
17:18simulacrumbackend being the http API we expose
17:18aturongood question
17:18acrichtoaturon: I feel like the lesson there is a bit extreme
17:18acrichtobecuase that basically means we're hamstrung as a team to do anything
17:18acrichtoin terms of interpreting it at face value
17:18simulacrumacrichto: I think the point here isn't that we don't do anything
17:19simulacrumIt's more so that we give at least a couple days notice for stuff like this
17:19acrichtoright yes, but we also need to mvoe faster than molasses
17:19aturonhm yeah, so maybe let's back up
17:19aturonthe servo team was pretty upset about this,
17:19aturonand it wasn't a case where we *knew* they were using this data and ignored it
17:20aturonso my goal is to develop a policy that will help prevent this kind of missed usage in the future
17:20simulacrumthough it is worth pointing out that we added alt builds for them
17:20simulacrumI think we should aim to keep better track of what artifacts people are using
17:20acrichtoright that makes sense, but I don't think we can say that we have to announce "literally everything" up to weeks in advance
17:20acrichtowe typically know what's being used and what isn't
17:20aturonbut that's precisely the problem
17:20acrichtofor example we knew servo was using the alt buckets
17:20simulacrumPerhaps we can say that moving forward on static.r-l.o is "public"
17:20acrichtowe just didn't know they'd have such a visceral reaction
17:21aturonhm so i wasn't in the discussions re: deleting
17:21simulacrumI didn't really know that Servo was using these -- I sort of assumed that they used something out of static.r-l.o
17:21aturonright so one approach would be to draw a very clear line between "public" and "private" resources, and communicate that out
17:21acrichtohm ok so "we knew" I think means "alex knew and didn't bring it up during the discussion as he didn't realize it mattered"
17:22aturonand then apply this policy to "public" resources only
17:22acrichtoyeah that seems totally fine to me, but we've sort of already done that
17:22acrichtoor maybe we didn't message that rust-lang-ci was private enough?
17:22acrichto(even though I sort of feel like we really did)
17:22aturoni don't think it was clearly communicated
17:22aturonare the alt builds available anywhere else?
17:22acrichtoI mean, we told servo at every step of the way "this is a hack and it may change"
17:22acrichtohow much more clearer could we have been?
17:22acrichtothe alt builds aren't anywhere else
17:23acrichtobut also to be clear the technical details are that we're retaining these builds for 90 days
17:23aturonin any case, we don't need to rehash this particular instance to death
17:23acrichtoso it means that (a) servo must update at least every 90 days and (b) historical ones won't build so easily
17:23notriddlePut private / unstable / unsafe or something in the URL?
17:23aturonlet's come back to the -alt build long-term strategy in a minute
17:24ericktI also think we ought to work towards making some of these resources even more private
17:24aturonso to recap, some reasonable action items might be:
17:24ericktso only accessible inside our build environments
17:24aturon- comb through our publicly-accessible resources, determine which are public and which private
17:25aturon- put up a highly visible page documenting this, and making clear that we provide no guarantees about private resources; we can delete without notification
17:25aidanhsI somewhat implicitly assumed we'd keep things around for at least a few weeks after announcing, which might be a reasonable route for deleting things in general?
17:25acrichtoaturon sounds good to me yeah
17:25arielbyaturon: one point
17:25ericktand when we do this the first time, lets not actually delete, just make it inaccessible
17:25ericktor at least move it out of the way
17:25arielbyeven I was convinced that the bors uploads are public
17:25aturonaidanhs: that was sort of the initial proposal, but i think acrichto is worried about what that would mean for more private resources
17:25aidanhsor, I just remembered another thing I used to do- ^what erickt says
17:25ericktsince people might not see the notice
17:25aturonaidanhs: e.g. things like perf that we may want to change rapidly
17:26arielbyat least in the sense of "shouldn't change without a post on i.rl.o"
17:26kennytmerickt: what's the difference between 'delete' and 'inaccessible' from the pov of the outside world?
17:26aturonkennytm: whether the data can be recovered
17:26aturonservo was relying on this data for bissections
17:26aturonso not "urgent", but the lost data means they now have a limited window for bissections
17:26aidanhskennytm: you can restore access after the week long brown-out
17:27aturonarielby: thanks for the data point
17:27aturonso i think the action items i highlighted are a *minimum* step here
17:27simulacrumservo was relying on this for *builds* I thought?
17:27arielbyso we should make sure that it is more obvious what is "public" and in which sense
17:27arielbywhich level of publicness
17:27aturonsimulacrum: each servo commit is tied to a particular compiler artifact
17:28aturonsimulacrum: so if they want to bissect a bug in servo, that involves building past commits,
17:28aturonsimulacrum: which in general needs those artifacts to be present
17:28aidanhsaturon: I'm trying to think through your point - what about perf might change that people would be relying on (just as an example)?
17:29aturonaidanhs: from simulacrum, "perf.rlo's data and backend are in flux constantly, and I change those somewhat often"
17:29aidanhsah got it
17:29aturonso we need a balance
17:29aturoni agree with acrichto that it's unacceptable to hamstring ourselves on what we *intend* to be purely "private" infra
17:30aturonbut we need some way to signal that distinction clearly,
17:30simulacrumMy approach to perf.rlo's APIs and data is that "inherently unstable, don't rely on, may go absent at any point"
17:30aturonso that people know what they're buying into
17:30aturonbasically the equivalent of the unstable/stable distinction :)
17:30simulacrumI think it may be good to document only public APIs on forge.r-l.o perhaps
17:30aidanhswas just thinking that!
17:30aturonso i added a couple of action items to
17:30simulacrumand implicitly, we can say that anything not listed on forge.r-l.o is unstable and may vanish
17:30aturonanybody want to take one or both of those on?
17:30aturonsimulacrum: yeah
17:31tedwe have hit this situation *countless* times in mozilla history
17:31aturonted: ohai :)
17:31aidanhs+1 to what simulacrum says - I'm not sure that identifying private resources is a good use of time
17:31tedturn off or move service X, get a bunch of angry bugs/messages "hey i was using that!"
17:31simulacrumSo I guess I want to propose that we for now just list static.r-l.o as public
17:32simulacrumand in the announcement say "what are you using? tell us!"
17:32acrichtosimulacrum: that's what I'd think, yes
17:32est31ted: I use the compiler as my room heater
17:32est31ted: please dont make it fast
17:32est31I'll freeze
17:32tedand yeah, anything that is public will wind up with people using it because that's life
17:32aturonsimulacrum: acrichto: sounds great!
17:32aturonsimulacrum: want to make that post?
17:32simulacrumI can, yes. I'll get a rough draft ready today
17:32est31ted: xkcd on the topic:
17:32tedthe best you can do here is best-effort document ahead of time things that you intend to support as a public API, things that are intentionally not supported even if they are public
17:33shepThe secret "api" of the playground comes to mind as well ^_^
17:33tedand also try to announce ahead of time when you're making changes to things that haven't historically been bucketed as public or private
17:33aturonany thoughts on the policy around change for static.r-l.o?
17:33aturondo we consider it completely "stable"?
17:33aturonor do we permit changes with public consultation?
17:33acrichtocurrently, afaik, yes, it's 100% stable
17:34tedi dunno that you need to give like 2 weeks notice, but a post on a discussion board ahead of changes like that just to suss out any users goes a long way
17:34teda lot of times we've found that people are using something because they don't know there's a more suitable thing
17:34tedso you wind up getting people into a better place and unblocking your own work
17:35aturonacrichto: so how about: "intent is stable/permanent, and anything diverging from that will be publicly discussed beforehand"
17:35acrichtoaturon: sgtm1
17:35aturonted: right so this touches on the question of: what is the right policy for various "private" resources
17:35rustbotall the commands
17:35aturoni'm not sure there's a one-size-fits-all here
17:36aturonbut erickt's suggestion about "brownouts" is a good mitigation
17:36aturonand seems worthwhile for more "well-known" things like -ci
17:36aturonso, ok, simulacrum will make the post, and i'll write up a blurb for the forge
17:36tedyeah, i believe we've taken a similar strategy to that for turning off services
17:36simulacrumu.r-l.o or i.r-l.o?
17:36teddisable it for a week or two and see if anyone complains
17:37aturonsimulacrum: i
17:37tedso that you have a fallback plan (just re-enable it)
17:37aturonnext up: -alt builds
17:37tedthen after some grace period where nobody complains you can delete it
17:37aturonso the backstory, to get everybody in the loop here:
17:37arielbyyeah we shouldn't do irreversible changes
17:37arielbyunless there's a good reason to do them
17:37aturonnightly compilers currently enable LLVM assertions
17:38aturonwhich in the past has caught problems, especially for less well-tested archs
17:38aturonhowever, there's a compiler perf penalty in doing so
17:38aturoncompiler perf is a major issue for Servo, so they've looked for wins wherever they can
17:38simulacrumIs it worth making the statement that Tier 1 targets don't need LLVM asserts? Since they get tested more?
17:38aturonas such, we've been providing -alt artifacts, which are basically like nightlies without asserts on
17:39aturonsimulacrum: hm, i'm not sure i would go that far
17:39aturonacrichto: thoughts on ^ ?
17:39acrichtoaturon: sgtm as backstory so far
17:39aturonnote, the -alt artifacts are all for tier-1 targets AFAIK
17:39aturonacrichto: sorry, i meant simulacrum's question
17:39aidanhssimulacrum: I've found bugs in tier 1 platforms before
17:39acrichtoit's definitely an interesting question
17:39kennytmsimulacrum: i disagree, sometimes bugs from contributions can slip through when assertions are disabled
17:39aidanhsin fact it was the asserts that finally clued me in wtf was happening
17:40acrichtoI agree with aidanhs, but it's certainly rarer to find on tier 1 than it is on "weird platforms"
17:40aturonok, that's clear enough for now
17:40acrichtothat being said the compiler team would probably be best to answer such a question
17:40simulacrumyeah I'm fine with leaving them -- just wanted to make the suggestion
17:40aidanhsthere are less-tested paths even on tier 1 platforms (different memory models etc)
17:40acrichtoI feel as if LLVM asserts have fallen drastically over the past few months
17:40acrichtoer, year*
17:40aturonso, right now, we provide these special -alt builds specifically for Servo, on a few platforms
17:40aturonthat turn off asserts, and are otherwise like nightly
17:40aturonwe produce the artifacts, but don't hook them into rustup etc
17:41aturonso there are several inter-related questions here
17:41aturon1. at the very least, servo wants to be doing "the right thing" in terms of using *public* artifacts, but we currently only provide these in the -ci bucket
17:41aturon2. more generally, Servo and likely others would love to get these builds through rustup instead, i.e. make them first-class nightly targets
17:42aidanhsI don't know how much of this discussion is "current servo problem" and how much is "the future" but if we would like to solve servo's current bisect problem could we do 's3 symlinks' from the alt build urls to the nightlies?
17:42aturon(and clearly #2 resolves #1)
17:42aidanhsah but alt builds don't necessarily correspond to a nightly
17:42aturonaidanhs: that's not a bad idea! i think we should do so "on demand" though, i.e. let Servo know we'd be open to such a thing, but wait until a bisect actually needs it
17:42aidanhsmaybe if it's particularly painful for them we can offer a "closest nightly to alt build symlinks" a mitigation?
17:42acrichtoI've personally been very hesitant to produce a "new nightly toolchain" channel or such historically
17:43aidanhsyeah ok
17:43acrichtobut along those lines I think I've got an idea to solve servo's problem regradless
17:43acrichtoand basically keep doign what we're doing today w/ alt being "sort of hidden"
17:43aturonright so re: #2, we've had this discussion a few times in a few venues, and never really clearly resolved it
17:43aturonacrichto: is your hesitation about the "everyone will switch to this toolchain so we'll lose the testing" concern, or something else?
17:43acrichtoit's a couple of factors --
17:44aidanhsI too would like #2 to work for personal reasons :)
17:44acrichtoone is that it's just double the stuff every night for a "niche" use case
17:44acrichtothe other is that why would anyone willingly use the slow variants?
17:44aturonoh so i assumed this would be for select platforms only, not everything
17:44acrichto(aka we'd have tons of "10 tips for fast rust" all over the interenet recomending the non-defaults)
17:44acrichtoit's true that'd help the binary size problem
17:45shep"number 3 shocks the Infra team"
17:45aidanhsmmm, I suspect the platforms servo would want would account for 80% of installs
17:45acrichtobut I also feel like if we have enough desire to turn off asserts we should just turn off asserts
17:45aturonacrichto: how many alts do we have right now -- like 6?
17:45acrichto(across the board)
17:45acrichtoaturon: I think 3 or 4
17:45acrichto(only x86_64, not i686)
17:45aturonah ok
17:45aturonyeah so the request would be basically to do the same builds we're doing today
17:45aturonjust make them "official" and accessible through rustup
17:46acrichtoer well so along those lines
17:46acrichtoone possible solution, without making anything official and/or new
17:46acrichtois for servo to only use nightlies
17:46acrichtoe.g. the commits that correspond to actual nightlies
17:46acrichtoand then they have a "fast path" where they attempt to download the "no asserts build"
17:46acrichtoand if that fails it just falls back to normal assert-ridden artifacs
17:46acrichtoso every day development would work just fine
17:46acrichtobisects historically would work fine
17:47simulacrumSo they'd go to rust-lang-ci2 bucket and then fall back to nightly?
17:47aturonso it's a question of whether we want to make this improved perf more widely-available
17:47simulacrum(giving them ~90 day period in which they're "fast")
17:47aturonwhich is not really an infra question :)
17:47acrichtobut yeah that's sort of my thinking aturon
17:47acrichtoit's probably not up to just us how broadly we want to make these vailable
17:47shepI assume for the type of bisection they are doing, they don't always want assertions enabled?
17:48simulacrumMy answer would be to move people off nightly, to an extent, but probably more core team, maybe compiler team (optimizations to make asserts not all that bad)
17:48acrichtoif we as a project (whomever should make such a decision) decide to do assert-free builds we can get it done
17:48aturonbut so to be clear, if we *did* want to make these 3-4 first-class, infra-wise we're fine
17:48aturonshep: i doubt the asserts would make a difference
17:48acrichtoaturon: in terms of capacity to produce the artifacts, yes, but we'd still need work to actually figure out how to deploy them to and integrate into rustup and manifests
17:48aidanhsshep: if your llvm is asserting now, your builds before were likely horribly broken
17:49aturonthere's *work* but it seems plausible
17:49acrichtoaturon: indeed yeah
17:49aturonok, so i propose to take this decision (whether to do this "optimization" for Servo vs. make the builds first-class) up to the core team
17:49aidanhsaturon: this seems like a similar question to the builders one - there's nothing stopping in principle, but it comes down to who this is for and who pays
17:49aidanhs(this is an easier question for servo ;)
17:49aturonlol indeed
17:50aturonalright cool, let's move on to our final topic
17:50kennytmbtw, the assertions are currently unconditionally disabled on macOS, even on non-alt builds.
17:50aturonso we probably won't have time to get all the way through this, but i wanted to do a kind of general "check in"
17:50aturonon the roadmap, impl period, etc
17:50aturonroadmap is here:
17:51aturonthere are two major questions on my mind:
17:51aturon1. should we consider "consolidating" the infra WGs, to try to get more activity/progress by cutting scope a bit?
17:51aturon2. should we consider re-prioritizing to look at Travis alternatives in more depth sooner?
17:52aturonbut first -- how are we looking on our september goals?
17:52simulacrumIn a way, perf is "great"
17:52simulacrumI don't see rustbuild on there
17:52aturonmm yes, this document predates the WG formation
17:52aidanhsweelll...crater kinda stomped on my cfg milestones
17:52simulacrumperf has been undergoing major improvements -- I think we could see more contributors, but not sure what to do about that really. Mentoring issues is somewhat hard.
17:52aidanhsbut I'm happy with where crater is going
17:52aturon(this doc may no longer be so useful, compared to the WG pages)
17:53aturonaidanhs: yeah i get the sense that you are stretched pretty thin
17:53simulacrum(in that, I can come up with tasks -- but I don't have ready-to-go instructions really)
17:53aturonsimulacrum: glad to hear that about perf
17:53ericktI'm pro consolidating the WG. the security one is semi-active, which is great, but having a more active channel might make things more sticky
17:53aturonhm, so trying to think how to make the next 7 mintues most useful :)
17:53aidanhsnow crater is 'contributor ready', I'm going to work on cfg a bit
17:54simulacrumrustbuild is ~okay, but again, is somewhat blocked on contributors (my time is limited)
17:54aturonsimulacrum: have you gotten much actvitiy?
17:54aturoncontributor-wise i mean
17:54simulacrumNo to both rustbuild and perf
17:54aidanhsso cfg is an ideal one to be unified with security, but I think there may end up being culture clash (or would be if cfg had anyone)
17:54aturonfor reference, the full WG set is {, perf, crater, secure, host, rustbuild}
17:54simulacrumMore so on rustbuild, but that was primarily compiler devs (petrochenkov, IIRC)
17:54aidanhs*cfg -> host
17:55aturoni think has gotten a pretty steady stream
17:55aidanhsI reckon maybe host and secure get folded and me and erickt keep an eye on things
17:56aturonany thoughts on further steps we can take to help host + crater make more progress?
17:56aturonaidanhs: sounds like you're more set up for contributors now on crater?
17:56simulacrumCrater -- I haven't looked at the new instructions yet, but if those help new people get onboard, that'd be great
17:56aidanhsyeah, in that they can actually run it locally
17:56aidanhs(per internals post today)
17:56simulacrumIt's currently down for beta/PR runs but I think I have a fix
17:56aturonaidanhs: ooh, i hadn't seen that yet
17:56simulacrum(currently testing on beta)
17:56aidanhsI'd like to drop it from 6 steps to 3, but it's not too bad
17:57aturonre: host, i get the feeling that one problem is that it's just not clear what contributors should *do*
17:57aidanhsthat's another great thing about the local running of crater - simulacrum can now repro the issue locally and we can test the fix in travis :)
17:57aturonbut it sounds like, aidanhs, you plan to put more attention on that soon
17:57aturonhah :)
17:57aidanhshost is...tricky
17:58aidanhsa lot of it is running around talking to people, but I've tried to lay out some concrete plans in the doc
17:58aidanhs("learn about aws secrets, do a poc in ruststatus")
17:58aturonok, so action item: merge secure+host (i'll follow up later on that)
17:58aturonin the last two minutes, the other question --
17:58aturondo we need to step up our attention on non-Travis solutions?
17:59aidanhsbut I just don't know how many infra people end up using rust
17:59aturonit seems like we've been able to keep the queue from growing completely out of bound
17:59simulacrumRollups are a cause
17:59aidanhs(maybe that's an area of future outreach)
17:59simulacrumand a few core people being busy with a single PR
17:59aidanhswell I think we've finally gotten at least some attention from travis with the graphs
17:59aturonso my concrete concern is that this will eventually end up harming the impl period elsewhere
18:00aturonbut OTOH, i don't want to steal momentum away from our WGs
18:00simulacrumin theory, if PR queue is fine, then alt. solutions aren't needed?
18:00simulacrumBut, also, it's worth pointing out that some are probably discouraged b/c of PR queue length (even though its somewhat low)
18:00aidanhsacrichto: how long did the last migration take?
18:00aturonyeah, if we anticipate it staying "fine"
18:00aturongrr, gotta run to my next meeting
18:00aidanhsI wouldn't want to bet on it taking less than a month, especially with new bugs we find...
18:00simulacrumlow by our standards that is
18:00acrichtoaidanhs: er sorry, which migration/
18:01aidanhsfrom buildbot to travis
18:01aturonbut my gut sense here is that it's still not time to push hard on this
18:01acrichtooh lord, months?
18:01simulacrumYeah, let's not push on this too hard I think
18:01acrichtoer yes we shouldn't be pushing on going away from travis
18:01aturonok, thanks all, gotta run!
18:01simulacrumIf Travis continues being unresponsive, we can talk mroe
18:02simulacrumanyway, I have to run too -- thanks all
18:03SimonSapinIts definitely discouraging when a PR of mine lands days after "r+" because of queue length, fwiw
18:14notriddleBTW, how's it going on the shared inbox stuff?
17 Oct 2017
Last message: 2 hours and 33 minutes ago