mozilla :: #rust-infra

17 Apr 2017
01:11simulacrumacrichto: Is there a way to have artifacts for the individual parts of a rollup merge (just for x86)? I suspect that's hard, so probably not something we can support
01:29simulacrumI'm happy to announce I have an almost working version of perf.rlo locally
01:29simulacrumJust backwards/forwards navigation and the summary page left, really, although I'm sure I introduced some bugs at least
01:54simulacrumbrson, edunham: Do you know who has access to the frontend/backend for perf.rlo? (not the collection infrastructure, just the actual HTTP server)
11:57carols10centsHAPPY MONDAY INFRASTRUCTURE TEAM!!
12:12carols10centsi changed my mind about the gradual phase-in, i was thinking about it mostly in terms of the aggressive pinging of reviewers
12:12carols10centsbut the longer pings of authors, like i think this one should get the week ping https://github.com/rust-lang/rust/pull/39556#issuecomment-290952680
12:41eddybcarols10cents: heh. I would've waited for the whole easter thing to end
12:41carols10centseddyb: meh. i'm commenting on things that havent seen any activity since way before the whole easter thing started
12:42eddybI guess people will see the pings when they get back anyway
12:45carols10centsi got through unlabeled and waiting on author. i gotta go do a thing, will be back in about an hour to finish :)
12:47Manishearthaturon: acrichto well this is broken
12:47Manishearthinfra
12:47Manishearthoops
12:47Manishearthhttps://github.com/rust-lang/rust/pull/40123#issuecomment-294479724
12:50Manishearthnagbot is forwarding emails for these issues to my mozilla account
12:50Manishearth(a) pls not the mozilla account :)
12:50Manishearth(b) is this infra team stuff?
12:50Manishearth(c) I should not be able to reply to it and have nagbot post a comment :)
13:41arielbyedunham: how's the perf.rust-lang.org frontend going?
14:03carols10centsManishearth: a) o.O
14:03carols10centsManishearth: b) probably
14:04carols10centsManishearth: c) o.O
14:10carols10centsManishearth: i don't know much about nagbot but if it's a problem with creds/config of nagbot i think acrichto has to fix it as part of https://github.com/alexcrichton/rust-central-station secrets
14:11carols10centsidk who else has permissions on rust central station (yes yes erickt is vindicated again)
14:30arielbycarols10cents: open a PR?
14:30carols10centsarielby: doing what where?
14:30arielbyopen a PR to RCS
14:31carols10centsarielby: to do what
14:31arielbythe nagbot thing
14:31carols10centsarielby: i have no idea what needs to change
14:31arielbyah didn't notice timestamps
14:31arielbythen Manishearth can open a PR to RCS
14:31carols10centsarielby: also the config is totally in secrets that i assume live in the docker image, not the repo
14:32carols10centsi have no idea if the problem is with the rcs *code* or the rcs *config*
14:32carols10centsif it's config, then the change needs to be made in secrets.toml that is a copy of https://github.com/alexcrichton/rust-central-station/blob/master/secrets.toml.example that presumably only acrichto has access to
14:34arielbythe nagbot config shouldn't be in secrets.toml
14:34arielbyonly the secrets
14:35carols10centsi dont know what the problem is tho
14:36carols10centsthere's totally nagbot config in secrets https://github.com/alexcrichton/rust-central-station/blob/master/secrets.toml.example#L34
14:36arielbythat's just the username & password
14:36carols10centsarielby: do you know what the problem is with nagbot that Manishearth is experiencing?
14:37arielbybut nagbot does not seem to have code to send e-mails about bors failures
14:37arielbyI mean, https://github.com/aturon/nag-rs/commits/master
14:37arielbynot updated since march
14:38carols10centsyes, and?
14:38carols10centswhat does that mean?
14:38carols10centsi have 0 context on what nagbot does
14:38arielbythe "send-email-on-bors-failure" feature is newer than thart
14:38arielbyso it's some other bot
14:38arielbyusing nagbot's creds
14:39arielbyacrichto & aturon : do you know which bot is sending the bors failure emails?
14:39arielbyactually, the e-mail comes from notifications@github.com
14:40arielbyand Reply-To: Reply-To: rust-lang/rust <reply+01a3cdd0a94cd4462b456f07b83af4a860f4718794c88e5792cf00000001150b5e2792a169ce0d3ba25e@reply.github.com>
14:43arielbyand To: rust-lang/rust <rust@noreply.github.com>
14:44arielbyso it sends an e-mail to the entire project
14:44frewsxcvTimNN: why did you retry here? https://github.com/rust-lang/rust/pull/40123#issuecomment-294499565
14:45TimNNI forgot to push some commits to rust-lang/llvm
14:45TimNN(Sorry I forgot to add the reason)
14:47arielbyTimNN: can you cherry-pick the merges?
14:47arielbyso we&#39;ll have the PR attached to each backported commit?
14:50TimNNarielby: Yeah probably, although some of those don&#39;t have merge commits
14:50TimNNeg https://github.com/rust-lang/llvm/pull/39
14:51arielbyand it&#39;s still not upstreamed?
14:51arielbyit&#39;s p. old
14:52TimNNarielby: how about just adding the PR number to the commit messages?
14:53arielbyI&#39;ll prefer adding it in a merge commit
14:53arielbybecause the commit itself is a cherry-pick from LLVM
14:54TimNNarielby: Alright, lets see how the test go and I&#39;ll update the PR afterwards.
15:03carols10centsuhhhh idk if i&#39;m doing this right https://github.com/rust-lang/rust/pull/40113#issuecomment-294503765
15:03carols10centsi dont see anything happening
15:03carols10centsshould i rebuild in travis instead...?
15:08TimNNarielby: I&#39;m currently trying the cherry-pick merge commits thing
15:09arielbyTimNN: you can also cherry-pick the inner commit
15:09TimNNIs it expected that the merge commits lose their merge commit property (ie, they only have one parent)
15:09arielbyand then do the `git merge --no-ff`
15:10arielbydon&#39;t you need `-m`?
15:10TimNNarielby: yeah
15:10TimNN-m1 produces the behaviour sescribed
15:10TimNN-m2 says empty commit
15:11arielbyidk
15:11arielbycherry-pick the inner and create the merge yourself
15:12TimNNidk either :( What exactly did you mean with the merge --no-ff
15:12TimNNdoesn&#39;t that need some remote branch?
15:13arielbythere&#39;s `git rebase -p`
15:14TimNNHow would you use that here?
15:16arielbygit rebase -p --onto HEAD merge-commit{^,}
15:18TimNNarielby: Thanks, that seems to work!
15:18arielbythis detaches HEAD so you have to reset your branch back
15:18arielbythere is probably a way to use git rebase --onto that does not detach HEAD
15:18arielbybut I don&#39;t know what it is
15:19TimNNYeah I noticed, but that should be easily fixable
15:21arielbyI want `git cherry-pick -p`
15:50aturonManishearth: arielby: carols10cents: so this nagbot email was just the quickest way last week of emailing everybody on infra-team@rust-lang.org when a bors failure occurs
15:50aturonManishearth: arielby: you should also have received an email from me talking about that email alias
15:50aturonif you&#39;d prefer not to be on it, that&#39;s fine
15:51aturonemails there are currently going to about a dozen people (not the entire team)
15:51aturonManishearth: i can also change your email address if you tell me what you prefer
15:51aturonin terms of being able to reply on behalf of nagbot... i agree that&#39;s bad :)
15:51arielbywhat code is doing that?
15:51aturonright now it&#39;s just forwarding through gmail (which is where nagbot&#39;s account is set up)
15:52aturonwhoa, github offers suggested reviewers now
15:53aturonif someone wants to do something more principled for pushing notifications on bors failures, please let me know
15:53aturoni don&#39;t have time to do anything more on it at the moment
15:56aturoncarols10cents: simulacrum: i&#39;m thinking we may need to rename S-waiting-for-reviewer to clarify that it shouldn&#39;t be applied until the reviewer has already responded
15:56aturonalternatively, we could consider having an additional tag to separate the initial review from follow-up
16:11aturonsimulacrum: i&#39;m trying to finalize the meeting schedule, and it looks like you&#39;re the most constrained (which is making it a bit tricky). i&#39;m wondering if you could possibly meet a half hour earlier than the final slot?
16:11aturon(i only gave hour increments)
16:22carols10centsaturon: agreed on the S-waiting-for-reviewer being confusing
16:26aturoncarols10cents: got a sec to discuss the overall flowchart?
16:27carols10centsaturon: yup!
16:40aturoncarols10cents: lol, and of course i missed your reply... how &#39;bout now?
16:42carols10centsaturon: sure! what medium?
16:43aturoncarols10cents: let&#39;s try here quickly and go vidyo if needed
16:43carols10centsaturon:
16:43carols10centswhat&#39;s on your mind?
16:43aturonok so i was just reflecting on the confusion around the review status, and noticed something
16:44aturonthe core value of these statuses is to determine *how often a PR is looked at*
16:44aturonunlabeled is daily
16:44aturonreviewer is 3 days
16:44aturonauthor is 1 week
16:44* carols10cents hums it&#39;s been... 1 week
16:44aturonhowever, with unlabeled, we&#39;re supposed to leave a comment right away,
16:45aturonand *then* wait 3 days for reviewer
16:45carols10centswell, if there hasn&#39;t been any activity in 24 hrs
16:45aturonyeah
16:45aturon(though it&#39;d be fine to leave a comment immediately, honestly)
16:45aturonso, first thing: i don&#39;t think there&#39;s any harm actually in assigning waiting-for-review right away
16:45carols10centsok!
16:46aturonit just means that, when you revisit those, you need to look at the comment history a bit to figure out what to do
16:46carols10centsas soon as that &quot;first human contact&quot; goes
16:46aturonright
16:46aturonso then the other thing i was wondering is:
16:46carols10centswhich, yeah, as i was doing review this morning, i went through all the unlabeled, reviewer, and author PRs
16:46carols10centsand read all the comments
16:46aturonhow much value is there in waiting-on-author vs waiting-on-reviewer
16:46carols10centswhich we&#39;ll need to do to check that statuses have been updated
16:46aturoni.e. 5 day interval vs 3 day interval
16:47aturonvs basically just triaging all unlabeled things daily, all labeled things after 3 days
16:47aturon(since as you say you have to read the comments anyway)
16:47carols10centsin my mind it&#39;s how aggressive we should ping rust team members vs how often we should ping people contributing in their spare time
16:48aturonright --
16:48aturonsorry, let me be more clear
16:48aturoni&#39;m talking only about how often we *look* at a PR
16:48aturonthe actual pinging etc would follow the same rubric
16:48carols10centsok
16:48aturonwdyt?
16:48aturoni can&#39;t tell if that streamlines things
16:48aturoni guess one benefit of having them split is the tracking we get
16:48carols10centsso the other problem i&#39;m running into
16:48carols10centsis that last modified on github isn&#39;t really helpful
16:49carols10centssince our labels/pings modify
16:49carols10centsso i still have to open everything
16:49carols10centsto see *what* modified
16:49aturonhrm yeah
16:49carols10centseventually we might be able to go by PR opened time only
16:50carols10centsbut starting out there&#39;s a lot of old PRs we&#39;re catching up
16:50aturonso if we tweaked things we might be able to make all of our activities happen on a multiplied interval
16:50aturonlike, if whenever we do a thing, the earliest the next thing happens is 2 days
16:51aturondo you see what i mean?
16:51aturonhard to describe this clearly...
16:51carols10centsto cut down on the number of prs we have to look at each day
16:51aturonyeah that&#39;d be the goal
16:51carols10centsyeah that&#39;d be good
16:51aturonok lemme strawman something real quick and i&#39;ll gist you
16:52carols10centshere&#39;s one more off the wall thought: what if we had labels for M T W Th F
16:52carols10centsand the label indicates the next time someone will check in on that PR
16:52aturonoh interesting
16:53carols10centsso on your day, you query for the things labeled with your day
16:53carols10centsand then change the label to your day + 3 or whatevs
16:53aturonright
16:53aturonwell so one question is: do we see value in knowing the breakdown of PR states over time?
16:53aturon(the data we&#39;re starting to collect in the spreadsheet)
16:53carols10centsso partially
16:53carols10centsi think
16:53carols10centsthe sense i get is
16:54carols10centswe&#39;re in this crisis mode of &quot;prs are taking too long&quot;
16:54carols10centsand it&#39;s hard to tell why that is
16:54carols10centswe can&#39;t really do much about waiting for authors
16:54carols10centsbut we can about waiting for review/bors/etc
16:54aturon(though it&#39;s good to know if the reason it takes a while is due to authors)
16:54aturonyeah
16:54carols10centsright
16:54aturonactually i guess the day tags don&#39;t have to be exlusive with the S- tags
16:54carols10centsit&#39;s useful to know so that we can include it in analysis of why this is happening
16:54aturonnot sure why i was thinking they would be
16:55carols10centsyeah
16:55carols10centsi think they&#39;re good indicators for the participants in the PR too
16:55aturonmmm yes
16:55carols10centswho&#39;s court is this in
16:55carols10centsso that PRs don&#39;t hang out in this nebulous state of everyone thinking they&#39;re waiting on someone else
16:56aturonso the day tag thing feels more &quot;foolproof&quot; than trying to hack things so that we can use github&#39;s activity timestamps
16:57carols10centsyeah, but could be more fiddly
16:57aturonoh but there is one downside actually
16:57aturonwhich is, if we miss a day,
16:57aturonthe PR waits a whole extra week
16:57carols10centsyeah
16:57aturonhmmm ok, lemme do this sketch real quick trying to stick with roughly the current model
16:58carols10cents
16:58* carols10cents imagines a nagbot backstop that pings everyone on PRs that haven&#39;t seen activity in a week with this gif https://az616578.vo.msecnd.net/files/2016/05/22/635995442426261832770571027_anigif_enhanced-2329-1436145519-2.gif
17:11aturoncarols10cents: hey, got distracted a bit, but here&#39;s a sketch: https://gist.github.com/aturon/6da9fee0b2565b2237b2ca7fb6e826d7
17:12carols10centsaturon: i am really curious to know how you decide between google docs, etherpad, and gist when you&#39;re writing something :)
17:12aturonloooool
17:12carols10centsso we&#39;re switching to calendar day from weekday?
17:13aturoni thought that would make everything simpler
17:13aturon(we may want to inflate the timings here slightly)
17:13aturonso the key changes here are:
17:13aturon- everything gets labeled right away
17:14aturon- the waiting-on-review has a split depending on whether we&#39;ve heard from the reviewer at all
17:14aturon- all labeled things get looked at every 3 days
17:14aturon- times for actions are generally multiples of 3 days
17:15carols10centswaiting-on-review has a split *of potential actions*, not splitting the label into two labels (i&#39;m clear on this, just clarifying for anyone reading the chat but not the gist)
17:16carols10centsyeah i think we could try this
17:17aturonOK cool, i&#39;ll feed back into the google doc
17:21arielbywe don&#39;t have that much waiting-on-review prs
17:21arielbythat&#39;s only 20
17:21arielbyI think these are most importnat
17:21arielbythere&#39;s not much we can do about waiting-for-author
17:22arielbyand the queue (waiting-for-bors) is under control
17:31carols10centsok so this pr https://github.com/rust-lang/rust/pull/40113
17:31carols10centsshould i do r=alexcrichton ?
17:32carols10centshe approved it, it got r- because tests were failing, the pr was redone, alex expressed approval again https://github.com/rust-lang/rust/pull/40113#issuecomment-293323165
17:32arielbycarols10cents: I think we should wait for him
17:32carols10centsok :)
17:33arielbymake sure the rebase didn&#39;t break anything badly
17:34aturoncarols10cents: ok doc updated
17:34aturoncarols10cents: i had one more thought, which is that we could add a S-blocked tag as a catch-all for edge cases (blocked on another PR, WIP PRs, etc), and we just check in on those every week or so
17:35carols10cents
17:35arielbywhat&#39;s the difference between S-blocked and S-waiting-on-author?
17:35arielbythat S-waiting-on-author is for a small change?
17:35arielbybut with absentee authors, you never know
17:36aturonarielby: S-blocked was trying to address some of the special cases, like when one PR can&#39;t land until another one does, or when a PR is waiting on crater, etc
17:36aturonwaiting on author means the author specifically gets pinged, and the PR is closed after 2 weeks of inactivity
17:37carols10centsi would read s-blocked as &quot;take this out of the infra team process for some reason&quot;
17:37aturonblocked PRs could stay open indefinitely
17:37aturonyeah exactly
17:37aturonbut we just check in periodically to ensure that&#39;s the case (i think)
17:37aturontrying to keep this as simple as possible, and oriented around the typical case
17:37arielbywhat is the typical case?
17:38arielbyauthors disappearing for a week or 2 is quite common
17:38arielbybut in that case pinging them is ok
17:38aturonarielby: btw i added a breakdown of statuses and their descriptions to the doc
17:38carols10centsarielby: yes, that is in the typical workflow
17:38aturonarielby: yep, as is closing the PR
17:38aturonwhat&#39;s not typical is PRs that need another PR to land first
17:38aturonetc
17:39aturonarielby: do you object to adding S-blocked?
17:39arielbyaturon: I just want to know how to use it
17:39aturonare you thinking it&#39;s not clear enough?
17:39aturonhm ok
17:39aturonit&#39;s kind of like S-waiting-on-something-else
17:39arielbyI mean, if someone like camlorn or me opens a big PR
17:39arielbyand then gets busy/blocked
17:39arielbyI wouldn&#39;t like anyone to close it
17:39aturonwhy not?
17:40arielbyso S-waiting-on-author is &quot;waiting for an author we don&#39;t know&quot;
17:40arielbyand S-blocked is &quot;waiting for an author we know&quot;?
17:40aturonwhat&#39;s the problem with closing?
17:40arielbyactually, maybe it&#39;s better to have inactive PRs closed?
17:40aturonyeah, that&#39;s been our assumption, regardless of who they&#39;re from
17:40aturonthe difference with blocked, however,
17:40aturonis that they&#39;re inactive because they&#39;re waiting for some specific external thing to happen
17:41aturonso we need to make sure that they&#39;re not lost
17:41aturonwe could also not do blocked for now, but i know there are some PRs that don&#39;t fall into any of the current categories
17:42arielbyare there enough of them it&#39;s worth making a distinction from waiting-on-author?
17:42arielbyI mean, if a PR is WIP and the author goes absentee
17:42aturonmaybe not; basically we just say, in this case it&#39;s the author&#39;s responsibility to ensure progress?
17:42aturoncc carols10cents
17:42arielbythe case of &quot;PR blocked against something external&quot; should not be that common
17:42aturonagreed
17:42carols10centsshrug
17:42aturonok, let&#39;s do that for now
17:42arielbyI don&#39;t think there&#39;s much of a problem looking at these every week
17:43arielbyand telling the author &quot;hey, are you sure that didn&#39;t happen&quot;
17:43arielbyand of course there&#39;s *still* a problem if the author goes absentee
17:43arielbybecause they won&#39;t fix any rebase conflicts etc.
17:43aturonok cool, i&#39;ve updated accordingly
17:44arielbyso the desired flow
17:44arielbyis that if an author is busy
17:44arielbythey occasionally post &quot;I&#39;m still alive, just busy&quot;?
17:45arielbyor &quot;I can&#39;t find someone to help me with problem XYZ&quot;
17:45aturonyes, i think that&#39;s a good way to keep things moving
17:45aturonand if they opt not to do that, we&#39;ll do a gentle close, but make clear they can reopen at any point
17:46arielbysounds good
17:46arielbyand this is also the desired flow for &quot;blocked&quot; PRs
17:47aturonyep. thanks for nudging in that direction!
17:47arielbythe author should be making sure bitrot doesn&#39;t set it
17:47arielby*set in
17:58misdreavus4:30-5:30 on friday afternoons, oof
17:59aturonmisdreavus: sadly no time worked for everybody
18:00aturonmisdreavus: this one splits between you and simulacrum for availability
18:00aturonwould a different day at that time be better?
18:00misdreavusyeah, no big deal
18:00misdreavusdon&#39;t gate it on me
18:00misdreavusi haven&#39;t been very active here anyway
18:01aturonalright; we can also play with the timing as we go if it&#39;s not working well for people
18:06arielbyno fridays plz
18:06arielbywhere&#39;s the doodle?
18:13carols10centsarielby: aturon emailed it out last week
18:14arielbyI don&#39;t see any doodle in my e-mail
18:14arielbyI mean, I have the google doc
18:15arielbybut I don&#39;t see any reference to meeting times in it
18:29frewsxcvarielby: https://beta.doodle.com/poll/7pc4h6m5fagqgs8x
18:34arielbyso simulacrum basically can&#39;t attend before 2300 GMT?
18:35arielby*or 2230, rather
19:33frewsxcvscheduling is difficult
20:43simulacrumYeah, my schedule unfortunately often doesn&#39;t fit onto hour blocks
20:44simulacrumI&#39;ll be able to attend the latter half of Friday&#39;s meeting though
20:45simulacrumAnd will be around in the ~40-50 minute block before that
21:06arielbyedunham: what&#39;s the status of perf.rust-lang.org?
21:07simulacrumI just posted https://github.com/rust-lang-nursery/rustc-perf/pull/126
21:07simulacrumWhich at least locally makes everything that I could readily test work
21:07simulacrumarielby: ^
21:07simulacrum(and, yes, is a huge PR)
21:07arielbygreat
21:09simulacrumOnce that merges, or even before, I need someone (edunham? brson? acrichto?) to upload it to the server
21:10simulacrumBut the summary is &quot;nothing much has changed over the course of data collection&quot;
21:16* edunham takes a look, and hopes past self included the how-to-update instructions in the README
21:18edunhampulled the changes and restarted perf collection
21:19simulacrumPerf collection was working?
21:19simulacrumYou mean the server?
21:19simulacrumedunham: The ProxyPass directive *probably* needs to be updated from ProxyPass /perf http://localhost:2346 to ProxyPass / http://localhost:2346
21:19simulacrum(and same with Reverse)
21:20edunhamer, frontend. sorry, I was looking at the wrong thing and not at what I was typing.
21:20simulacrumAnd the command to start the server is now cargo run --release data, with the data repository probably needing to be recloned
21:20simulacrumOr, I guess, just pulled? Not sure if it&#39;s been kept up to date, but presumably not
21:22edunhamyeah we have the proxy path; cargo is just taking awhile because I asked it to do the build on a wimpy machine
21:22edunhamif we&#39;re going to be deploying changes to perf more often, I should really get Travis building the program so the perf host can just run it
21:22simulacrumedunham: You mean you updated the proxy path?
21:22simulacrumedunham: Yeah, travis builds it, it just doesn&#39;t upload it anywhere
21:23edunhamoh yeah reloading apache is darn helpful to get settings to change
21:23edunhamthe build is mostly to verify that it builds at all, right now
21:25simulacrumedunham: Let me know if it runs into any problems. Might be worth discussing with core team or whoever about seeing if we can get me access of some sort or at least automate the deploy, too, especially since that&#39;ll help encourage me do work more often :)
21:27aturonsimulacrum: yes
21:28edunhamaturon: imo we need a better story for handing out partial infra access
21:28aturonstrong +1
21:28aturoni will get this sorted with acrichto and brson once they&#39;re back from china
21:29edunhamaturon: i have the ability to hand out perms, but right now everything is accessed through the bastion and we don&#39;t have a strong system to say folks can only access a single host past the bastion
21:30aturonedunham: do you have a sense for what&#39;s involved in making it finer-grained?
21:30edunhamso, like, I could hand simulacrum perms that equate to access to everything (if he has a static IP somewhere to route through for us to whitelist), but that is almost certainly not the goal
21:32edunhamaturon: we basically have 2 choices: Find something smart to run on the bastion and harden it like crazy, or change the security story for our non-build infra to make it a little easier to access from the outside world
21:33aturonedunham: is the access list currently {brson, acrichto, edunham}?
21:33edunhamaturon: yep
21:34aturonedunham: want to get an email thread going with me and the two of them about this issue?
21:34edunhamaturon: sure!
21:34edunhamaturon: is this a just-us kind of thread, or an infra-team kind of thread?
21:34edunhamimo whole-infra-team might have some good input
23:02simulacrumFYI: I don&#39;t actually have any static IP at this point.
23:12aturonedunham: indeed! whole team sounds good
23:13edunhamaturon: ok, I&#39;ll do a bit of research on our options and then email about it :)
23:14aturonedunham: great, thanks!
23:42jntrnrnot sure if this is an infra question - but does anyone know how to list what build artefacts are available for a given nightly? Eg, getting a list of https://static.rust-lang.org/dist/2017-04-17/
23:56est31jntrnr: append index.html
23:56est31e.g.
23:56est31https://static.rust-lang.org/dist/2017-04-17/index.html
23:56est31or https://static.rust-lang.org/dist/index.html
23:56jntrnrest31: woot, thx
23:56jntrnrwow!
23:57jntrnrso it looks like rls is building as expected now
23:57jntrnrsounds like it might be time for that blog post
23:57jntrnracrichto: are we clear for a &quot;rls is now in nightly&quot; blog post?
18 Apr 2017
No messages
   
Last message: 39 days and 4 hours ago