If you’re interested in exploring tooling around stacked PRs, I wrote git-spice (https://abhinav.github.io/git-spice/) a while ago. It’s free and open-source, no strings attached.
The README covers the idea behind errtrace in more details, but the primary difference is in what is captured:
pkg/errors captures a stack trace of when the error occurred, and attaches it to the error. This information doesn't change as the error moves through the program.
errtrace captures a 'return trace'--every 'return' statement that the error passes through. This information is appended to at each return site.
This gives you a different view of the code path: the stack trace is the path that led to the error, while the return trace is the path that the error took to get to the user.
The difference is significant because in Go, errors are just plain values that you can store in a struct, pass between goroutines etc. When the error passes to another goroutine, the stack trace from the original goroutine can become less useful in debugging the root cause of the error.
As an example, the Try it out section (https://github.com/bracesdev/errtrace/#try-it-out) in the README includes an example of a semi-realistic program comparing the stack trace and the return trace for the same failure.
I'm a happy duck.com address user. I can answer these questions:
What it is: It gives you private throwaway email addresses.
Instead of signing up for a website with <real>@gmail.com, use <fixed>@duck.com. It will forward the email to <real>@gmail.com after removing any trackers from it.
It also lets you generate <random>@duck.com addresses on demand. If you sign up for something with <random>@duck.com, and they start spamming you, you can turn the email address off without doing anything to <real>@gmail.com or <fixed>@duck.com.
How to re-access it:
Information about your duck.com address is stored in that browser. If you use the Browser extension, that remembers it. You simply need to log into that email address from your current browser.
To do this, visit https://duckduckgo.com/email/, click on "I already have a Duck address", and enter your original <fixed>@duck.com address. It will email you a one-time password to <real>@gmail.com, and you'll be back in again.
Another option for recording gifs is LICEcap (http://www.cockos.com/licecap/). It supports OSX and Windows.
No support for overlaid keystrokes, though.
I believe you need to enable "Raw Message Delivery" in the subscription attributes for that subscription for it to deliver raw JSON content instead of wrapping your message in an envelope like that.
I honestly don't see a problem here. They decided to change a backend library for a non-essential system in their product. Most services don't ask for permission or make announcements when they make changes like this.
The approach seemed to be, if things break, people will report it and we’ll fix it.
While this may not be the best approach, the number of languages supported is too high for a person to check each one manually. Generally, I imagine they wouldn't expect a change like this to break anything significant.
[people] use it as a portfolio. [..] To suddenly doink the appearance of people’s portfolios is unfortunate.
It is very unlikely that syntax highlighting errors in GitHub will affect someone's chances of getting a job.
Sure, this switch could cause some issues but they don't seem to be severe enough to kick up a fuss over.
This is off the top of my head so maybe somebody will correct me, but:
Persona is a login system that cares about your privacy. With social login systems, the website you are logging into contacts the social login provider (Facebook/Google+/Twitter/what-have-you) when you attempt to log in. So you end up leaving a trail of breadcrumbs behind you of every site you visited (and used a social login on). Further, many people are not comfortable giving sites access to their social accounts because of privacy concerns.
With Persona, the idea is that your identity provider (can be your email provider, persona.org , or someone else) will have a key publicly available on their site. Your browser would generate a certificate that can be verified against that key. However, since the same key from the provider is used to authenticate all accounts on that provider, all the provider finds out when a website contacts it for the key is that someone is trying to log into said website. Plus, the website could cache the certificate and now the provider does not know this either.
There is more to this so you're probably better off reading one of the other links.