前段時間在使用 Pulsar 的 admin API 時,發現其中的一個接口響應非常慢:
admin.topics().getPartitionedStats(topic);
使用 curl 拿到的響應結果非常大,同時也非常耗時:
圖片
具體的 issue 在這里:https://github.com/apache/pulsar/issues/21200
后面經過分析,是因為某些 topic 的生產者和消費者非常多,導致這個查詢 topic 統計的接口數據量非常大。
圖片
但在我這個場景其實是不需要這些生產者和消費者信息的,現在就導致這個 topic 無法查看狀態,所以就建議新增兩個參數可以過濾這兩個字段。
因為涉及到新增 API 了,所以社區維護者就建議我起草一個提案試試:
圖片
此時就涉及到什么情況下需要給社區發起一個提案的問題了。
圖片
在官方的提案指南中有著詳細的說明,簡單來說就是:
首先第一步就是根據官方模版起草一個提案:重點描述背景、目的、詳細設計等。
圖片
并發起一個 PR,如果不確定怎么寫的話可以參考已經合并了的提案。
之后則是將這個 PR 發送到開發組郵箱中,讓社區成員參與討論。
圖片
這一步可能會比較耗時,提案內容可能會被反復修改。
發起提案的一個重要目的是可以讓社區成員進行討論,評估是否需要這個提案或者是否 有其他解決方法。
經過討論,如果提案獲得通過后就可以發起投票了,至少需要有三個 binding 通過的投票后這個提案就通過了。
雖然任何人都可以參與投票,但社區只會考慮 PMC 的投票建議;投票的時效性也只有 48h。
圖片
image.png
48 小時候便可以發一個投票結果的郵件,如果達到通過條件便可以通知參與投票的 PMC 合并這個 PR 了。
圖片
之后就是沒啥好說的實現過程,因為通常我們是需要在提案里詳細描述實現過程以及涉及到修改的地方。
只要提案被 review 通過后實現起來就非常簡單了,跟著提案里的流程實現就好了。
這點非常類似于我們在企業中對某個業務做技術方案,如果大家都按照類似的流程嚴格審核方案,那實現起來是非常快的,而且可以盡量的減少事后扯皮。
所以最后我的實現 PR 提交之后,都沒有任何的修改意見,直接就合并了;也大大降低了審核人員的負擔,提高整體效率。
以上就是我第一次參與 Pulsar 社區的提案過程,我猜測其他社區的流程也是大差不差;其中重點就是異步溝通;大家都認可之后真的會比實時通信的效率高很多。
具體的提案細節可以閱讀官方指南 https://github.com/apache/pulsar/blob/master/pip/README.md
本文鏈接:http://www.tebozhan.com/showinfo-26-51833-0.html如何給開源項目發起提案
聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。郵件:2376512515@qq.com
上一篇: Dubbo秘密傳遞:讓你的代碼行云流水
下一篇: 深入淺出內存管理:空間分配及逃逸分析