GitHub 引入 Code Owner 的概念

GitHub 推出了 Code Owner 的概念:「Introducing code owners」。也很直接說這個能是向 Chromium「致敬」出來的:

The code owners feature was inspired by Chromium's use of OWNERS files.

檔案名稱是 CODEOWNERS,可以放在根目錄或是 .github/ 下,可以針對不同的目錄設不同的人:

To specify code owners, create a file named CODEOWNERS in the repository's root directory (or in .github/ if you prefer) with the following format[.]

這樣一來,在 pull request 的時候就會跳出來:

另外也可以設定需要 code owner 同意才能 merge:

Facebook 與 Google Chrome 以及 Firefox 的人合作降低 Reload 使用的資源

Facebook 花了不少時間對付 reload 這件事情:「This browser tweak saved 60% of requests to Facebook」。

Facebook 的人發現有大量對靜態資源的 request 都是 304 (not modified) 回應:

In 2014 we found that 60% of requests for static resources resulted in a 304. Since content addressed URLs never change, this means there was an opportunity to optimize away 60% of static resource requests.

Google Chrome 很明顯偏高:

於是他們找出原因後,發現 Google Chrome 只要 POST 後的頁面都會 revalidate:

A piece of code in Chrome hinted at the answer to our question. This line of code listed a few reasons, including reload, for why Chrome might ask to revalidate resources on a page. For example, we found that Chrome would revalidate all resources on pages that were loaded from making a POST request.

然後在討論後認為這個行為不必要,就修掉了,可以看到降了非常多:

We worked with Chrome product managers and engineers and determined that this behavior was unique to Chrome and unnecessary. After fixing this, Chrome went from having 63% of its requests being conditional to 24% of them being conditional.

但還是很明顯比起其他瀏覽器偏高不少,在追問題後發現當輸入同樣的 url 時 (像是 Ctrl-L 或是 Cmd-L 然後直接按 enter),Google Chrome 會當作 reload:

The fact that the percentage of conditional requests from Chrome was still higher than other browsers seemed to indicate that we still had some opportunity here. We started looking into reloads and discovered that Chrome was treating same URL navigations as reloads while other browsers weren't.

不過這次推出修正後發現沒有大改變:(拿 production 測試 XDDD)

Chrome fixed the same URL behavior, but we didn't see a huge metric change. We began to discuss changing the behavior of the reload button with the Chrome team.

後來是針對 reload button 的行為修改,max-age 很長的就不 reload,比較短的就 reload。算是一種 workaround:

There was some debate about what to do, and we proposed a compromise where resources with a long max-age would never get revalidated, but that for resources with a shorter max-age the old behavior would apply. The Chrome team thought about this and decided to apply the change for all cached resources, not just the long-lived ones.

Google 也發了一篇說明這個新功能:「Reload, reloaded: faster and leaner page reloads」。

當 Facebook 的人找 Firefox 的人時,Firefox 決定另外定義哪些東西在 reload 時不需要 revalidate,而不像 Google Chrome 的 workaround:

Firefox chose to implement this directive in the form of a cache-control: immutable header.

Firefox 的人也寫了一篇「Using Immutable Caching To Speed Up The Web」解釋這個新功能。

所以之後規劃前後端的架構時又有東西要考慮進去...

舊 bug 新名字:httpoxy

依照慣例,security issue 都會取個名字,這次叫做 httpoxy:「A CGI application vulnerability for PHP, Go, Python and others」。

事情發生在兩個命名變數上的衝突:

  • RFC 3875 (The Common Gateway Interface (CGI) Version 1.1) 定義了 CGI 環境會把 Header 裡的 Proxy 欄位放到環境變數裡的 HTTP_PROXY
  • 而很多程式會拿環境變數裡的 HTTP_PROXY 當作 proxy 設定。

這件事情 2001 年在 libwww-perl 就有發生過 (並且修正),curl 也發生過 (然後修正),2012 年在 Ruby 的 Net::HTTP 也發生過 (也修正了)。

然後在 2016 年還是被發現有很多應用程式會中獎... 這頭好痛啊 :o

Dropbox 從 SPDY 切換到 HTTP/2 發現的現象

Dropbox 將本來的 SPDY 切換到 HTTP/2 後整理了不少資料:「Enabling HTTP/2 for Dropbox web services: experiences and observations」。

大多數都是效能的改善,但「Increased latency for POST requests.」這段頗有趣的,找出了 nginx 的 bug:

POST 的 latency 大約增加了 50%,而實際追蹤問題發現是 nginx 中 SETTINGS_INITIAL_WINDOW_SIZE 預設值的問題,然後提出 patch 改善:「[nginx] HTTP/2: rewritten handling of request body.」:

There is a small issue with setting `SETTINGS_INITIAL_WINDOW_SIZE` to 0: now when client tries to POST data it needs to wait for an additional RTT(between `send HEADERS` and `recv WINDOW_UPDATE`) to start sending data.

GitHub 加上 +1 與 -1 功能 (順便加上表情符號)

這是回應之前社群對 GitHub 的請願 (or 抱怨?) 而生的新功能,(參考先前的文章「GitHub 對 Open Source Community 請願的回應」):「Add Reactions to Pull Requests, Issues, and Comments」。

這避免了在討論時大量的 +1 與導致混亂的情況。

GitHub 對 Open Source Community 請願的回應

大約一個多月前 (2016 年一月 15 日),一群用 GitHub 發展 Open Source 軟體的人對 GitHub 提出請願,要求重視 Open Source Community 在 GitHub 平台上遇到的問題:「An open letter to GitHub from the maintainers of open source projects」。

這個請願在卡了將近一個月後,陸陸續續有相當多要搬出 GitHub 的討論,像是 eslint 就直接在 GitHub 開了 issue,討論搬出 GitHub 會遇到的問題以及可能的解決方法:「Investigate switching away from GitHub」。

在二月 13 日的時候,GitHub 透過 pull request 發出回應說「我們在處理了」,但也沒講正在處理什麼,看起來就是個很 PR 的回應:「Dear Open Source Maintainers」。

直到昨天,三個主要的請願中關於 issue 範本的問題 (也就是下面這段) 總算有進展了:

Issues are often filed missing crucial information like reproduction steps or version tested. We’d like issues to gain custom fields, along with a mechanism (such as a mandatory issue template, perhaps powered by a newissue.md in root as a likely-simple solution) for ensuring they are filled out in every issue.

為了解決使用者在開 issue 時有時會忘記給出完整的環境資訊 (以及其他有用的資料),GitHub 推出了新的功能,在開 issue 或 pull request 時利用 template 讓使用者有個範本可以照著填寫,同時 template 也支援 Markdown,讓填寫的方式會更豐富一些:「Issue and Pull Request templates」。

這總算開始有進展了。但也開始感覺到 GitHub 的動作已經開始慢下來了...

GitHub 上 Pull Request 的男女歧視問題

衛報報導了從 GitHub 上分析 pull request 的性別分析研究:「Women considered better coders – but only if they hide their gender」,原始論文出自「Gender bias in open source: Pull request acceptance of women versus men」。

研究的結果說明女性的 pull request 接受機率比男性高,但如果貢獻者可被確認是女性的話則會反過來,也就是說男女歧視問題是可被觀察到的:

Surprisingly, our results show that women's contributions tend to be accepted more often than men's. However, when a woman's gender is identifiable, they are rejected more often. Our results suggest that although women on GitHub may be more competent overall, bias against them exists nonetheless.

由於性別資訊不是必填項目,論文裡面也有提到透過 social network 的資料比對,以及其他方式去推測。這個研究成果看起來應該會產生不少討論...