Hướng dẫn cách xem xét các yêu cầu kéo (PR) được gửi đến Bitcoin Core

Tác giả: Jon Atack

Nguồn: https://jonatack.github.io/articles/how-to-review-pull-requests-in-bitcoin-core

giới thiệu

Việc xem xét và thử nghiệm có lẽ là những cách tốt nhất để bắt đầu đóng góp mã nguồn cho Bitcoin Core.

Việc xem xét và thử nghiệm kỹ lưỡng thường được các nhà phát triển Bitcoin Core lâu năm nhắc đến vì:

• Các nút thắt về nguồn lực và
• Đây là cách tốt nhất và hiệu quả nhất để học hỏi, bắt đầu đóng góp mã nguồn và xây dựng di sản của bạn trong cộng đồng.

Trước khi bạn bắt đầu

Hướng dẫn này dựa trên các tài liệu sau:

1. " Đóng góp vào Bitcoin Core: Kinh nghiệm cá nhân ," của John Newbery (2017)
2. " Hiểu rõ các khía cạnh kỹ thuật của Bitcoin ," của Pierre Rochard (2018).
3. Video / bản ghi / slide hội thảo chuyên sâu, của Jeremy Rubin (2018).

thuật ngữ

ACK và NACK : Định nghĩa và nguồn gốc của chúng có thể được tìm thấy ở đây và đây .

Sấy rận: Một vấn đề nhỏ thường không gây tắc nghẽn.

PR : Viết tắt của "pull request" (yêu cầu kéo ), đôi khi cũng được gọi là "merge request" (yêu cầu hợp nhất). Đó là một đề xuất thay đổi mã hoặc sách hướng dẫn trong kho mã nguồn.

WIP là viết tắt của " work in progress" (công việc đang tiến hành ).

Giáo dục đại cương

Là người mới, mục tiêu của chúng tôi là cố gắng đóng góp giá trị với thái độ thân thiện và khiêm tốn, đồng thời học hỏi càng nhiều càng tốt. (Mặc dù những mục tiêu này không chỉ phù hợp với người mới; hay nói đúng hơn, quá trình này không có hồi kết.)

Một cách tiếp cận tốt là không nên coi đó là điều bạn có thể kiểm soát, mà hãy tự hỏi: "Tôi có thể phục vụ mọi người tốt nhất bằng cách nào?"

Một trong những vấn đề khó khăn nhất đối diện những người đóng góp mới là quy mô của mã nguồn và độ phức tạp kỹ thuật xung quanh nó.

Hãy nhớ rằng có những điều bạn chưa biết. Các nhà phát triển lâu năm có nhiều năm kinh nghiệm và bối cảnh chuyên môn vững chắc. Cộng đồng đã xây dựng độ sâu. Hãy nhớ rằng, ý tưởng mới của bạn có thể đã được đề cập và xem xét nhiều lần trước đó.

Hãy nhớ rằng những người đóng góp và người quản lý dự án có thời gian và năng lượng hạn chế—hãy thận trọng và tôn trọng khi yêu cầu giúp đỡ. Mục tiêu là cho đi nhiều hơn yêu cầu, giúp đỡ nhiều hơn cản trở và đẩy nhanh tiến độ công việc.

Hãy cố gắng tự mình tìm hiểu mọi việc càng nhiều càng tốt, và ít nhất hãy tôn trọng thời gian của người khác.

Hãy theo dõi phòng chat trực tiếp #bitcoin-core-dev và danh sách gửi thư bitcoin-dev .

Bạn có thể tìm thấy thêm các kênh IRC đáng chú ý khác tại đây .

Bạn cần đầu tư lượng lớn thời gian trước khi bắt đầu:

• Hiểu rõ quy trình và chỉ dẫn đóng góp không chỉ đơn thuần là đọc sách hướng dẫntrong mã nguồn (đặc biệt là " Hướng dẫn đóng góp ", " Ghi chú dành cho nhà phát triển " và " Ghi chú về năng suất ") (và rộng hơn, mọi thứ trong tài liệu và mã nguồn kiểm thử ). Nó cũng đòi hỏi phải chú ý đến các tương tác trong kênh IRC #bitcoin-core-dev và các đánh giá mã liên tục trong mã nguồn .
• Hãy tìm hiểu về những người định kì đóng góp bài viết: họ làm gì, họ thích gì, họ muốn gì và họ tiếp nhận phản hồi như thế nào.

Nhiều người mới thường ngay lập tức mở các yêu cầu kéo (PR), nhưng điều này chỉ làm tăng thêm một PR nữa vào hàng trăm PR đang chờ được xem xét. Tốt hơn nhiều là nên xem xét các PR hiện có, hiểu loại PR nào hữu ích hơn và dần dần có được cái nhìn toàn diện về bức tranh tổng thể.

Một nguyên tắc hữu ích là: mỗi khi bạn chuẩn bị tạo một yêu cầu kéo (PR), hãy xem xét trước từ 5 đến 15 yêu cầu kéo khác.

toàn cảnh

Nhìn vào bức tranh tổng thể quan trọng hơn nhiều so với những chi tiết nhỏ nhặt, chính tả và kiểu viết mã.

Quá trình xem xét toàn diện có nhiều cấp độ khác nhau: "Sự thay đổi này sẽ ảnh hưởng đến những hành vi nào?" hoặc "Sự thay đổi này có an toàn không?" khác với "Đây có phải là một ý tưởng hay không?". Trả lời câu hỏi sau đòi hỏi nhiều bối cảnh hơn, điều mà bạn sẽ dần dần học được. Đừng để điều đó ngăn cản bạn suy nghĩ về những câu hỏi này, và đừng từ bỏ việc xem xét ở cấp độ này.

Các bước để nâng cao hiểu biết của bạn về ảnh toàn cảnh:

• Hoàn thành hướng dẫn học tập Chaincode Labs.
• Hãy cân nhắc đăng ký và tham gia khóa học trực tuyến Chaincode Labs được đánh giá cao (chương trình này cũng đóng vai trò như một công cụ tìm kiếm cho các nhà phát triển mới đang tìm kiếm việc làm liên quan Bitcoin và các dự án tài trợ mã nguồn mở ).
• Hãy nghiên cứu các đề xuất nâng cấp Bitcoin (thường được gọi tắt là "BIP") và thường xuyên xem xét chúng.
• Hãy đăng ký nhận bản tin Bitcoin Optech Weekly và sử dụng trang chủ đề của họ như một nguồn tài liệu tham khảo hữu ích.
• Hoàn thành khóa học " Học Bitcoin từ dòng lệnh "

Hãy ưu tiên chất lượng hơn số lượng, và tìm sự cân bằng giữa công việc chuyên sâu và kết quả nhanh chóng.

Việc viết tài liệu rất quan trọng. Ví dụ, tài liệu cần bao gồm tóm tắt cách thức hoạt động và tương tác của từng thành phần, tài liệu mã nguồn rõ ràng và chính xác, hướng dẫn về việc một hàm có dấu hiệu (sign) hay không, tài liệu Doxygen , nhật ký kiểm thử (bao gồm cả nhật ký info và debug ), v.v.

Độ bao phủ kiểm thử cũng rất quan trọng. Đừng ngần ngại cải thiện và viết thêm bất kỳ bài kiểm thử đơn vị , bài kiểm thử chức năng và bài kiểm thử mờ nào còn thiếu.

Hãy là một người đóng góp khiêm tốn và thân thiện. Giúp thúc đẩy các yêu cầu kéo (PR) bằng cách xem xét chúng, đề xuất các bài kiểm tra và các bản sửa lỗi hữu ích, đề xuất việc tái cấu trúc mã, và thậm chí xem xét việc tiếp quản sau khi một PR đã bị bỏ dở trong nhiều tháng. Tóm lại, hãy giúp đỡ lẫn nhau!

NIT

Cố gắng tránh quá sa đà vào những chi tiết vụn vặt và kiểu viết mã trong một PR, đặc biệt là những PR vẫn còn được gắn nhãn "WIP"; và đừng vội vàng soi mói khi một PR vừa mới được tạo và các tác giả vẫn đang tìm kiếm sự chấp thuận về mặt khái niệm và phương pháp(ví dụ như khi họ vẫn đang tìm kiếm sự đồng thuận chung).

Những người đóng góp lâu năm báo cáo những hoạt động như vậy gây khó chịu; hơn nữa, làm như vậy sẽ làm giảm vốn xã hội của bạn trong dự án. Hãy cố gắng hiểu loại đánh giá nào mọi người cần và khi nào thì cần thiết.

Thời điểm tốt nhất để bình luận về bất kỳ chi tiết nhỏ nào là sau khi PR đã nhận được đủ số lượng ACK (tức là sự đồng thuận) về khái niệm/ phương pháp, nhưng trước khi PR đóng và nhận được "tested ACK". Như Pieter Wuille đã nói trên IRC : "Tôi cảm thấy điều gây khó chịu nhất đối với một PR là nhận được lượng lớn bình luận về chi tiết/lỗi nhỏ/phong cách mã hóa mà vẫn không biết liệu PR đó có phải là một khái niệm tốt hay không."

Khi đưa ra lời khuyên về các chi tiết nhỏ và phong cách lập trình, cần phải thân thiện, thoải mái và mang tính khích lệ—ví dụ: "Cứ thoải mái bỏ qua nếu muốn," hoặc "Nếu bạn có thay đổi mã, bạn có thể điều chỉnh cho phù hợp," v.v.

Xin hãy nhớ rằng không ai có nghĩa vụ phải xem xét các nhận xét của bạn; nếu tác giả cho rằng nhận xét của bạn vượt quá phạm vi của những thay đổi và do đó trả lời rằng họ không muốn áp dụng chúng, điều đó hoàn toàn có thể chấp nhận được (đặc biệt khi nhận xét của bạn chỉ toàn là những lỗi nhỏ).

cải thiện

Khi có thể, hãy tăng độ khó và mức độ ưu tiên của các yêu cầu kéo (PR) mà bạn xem xét.

Chất lượng của các bài đánh giá quan trọng hơn nhiều so với số lượng. Bạn có thể học hỏi và tạo ra nhiều giá trị hơn bằng cách cung cấp các bài đánh giá chuyên sâu, chất lượng cao cho các yêu cầu kéo (PR) ưu tiên cao và khó xử lý hơn. Những PR này có thể khiến mọi người sụp đổ và bị trì trệ trong nhiều tháng, niềm đam mê của họ bị bào mòn bởi sự thiếu hụt các bài đánh giá chất lượng cao, những lời chỉ trích nhỏ nhặt về kiểu mã và các bình luận về rebase. Việc đánh giá chúng một cách đúng đắn thực sự là một đóng góp quý giá cho Bitcoin.

Quá trình cải tiến cần thời gian; không gì có thể thay thế được nhiều năm đầu tư vào việc hiểu rõ bối cảnh, chú ý đến mã nguồn , báo cáo sự cố, báo cáo yêu cầu kéo (PR) , kênh IRC #bitcoin-core-dev và danh sách gửi thư bitcoin-dev .

Trước khi bắt đầu quá trình xem xét, một câu hỏi hữu ích là: "Điều cần thiết nhất ở giai đoạn này là gì?" Trả lời câu hỏi này đòi hỏi kinh nghiệm và kiến ​​thức bối cảnh tích lũy, nhưng giá trị của nó nằm ở việc xác định cách tạo ra giá trị tối đa với thời gian tối thiểu. Tùy thuộc vào độ phức tạp và tầm quan trọng của thay đổi, và giai đoạn mà yêu cầu kéo (PR) đã trải qua trong quy trình xem xét, việc xem xét có thể chỉ bao gồm việc lướt qua mã và áp dụng kiến ​​thức bối cảnh lượng lớn vào một bình luận mã có liên quan tại một vị trí quan trọng, thay vì thực hiện một đánh giá đầy đủ bao gồm gỡ lỗi, phát triển, kiểm thử và xem xét mọi commit. Tuy nhiên, trong phần lớn các trường hợp, thực hiện một đánh giá toàn diện và bài bản là tốt nhất và mang lại giá trị cao nhất.

Từng bước một

Hãy gạt bỏ sự tự đánh giá và những ham muốn cá nhân. Đừng để mọi việc trở thành vấn đề cảm xúc cá nhân; thay vào đó, hãy thúc đẩy mọi thứ tiến lên.

Khi nghi ngờ, hãy cho rằng người kia có ý tốt.

Hãy kiên nhẫn với mọi người và với kết quả.

Lời khen ngợi công khai; lời phê bình riêng tư, nhưng cần đi kèm với sự khích lệ.

Hãy tiếp tục giúp đỡ người khác. Hãy nỗ lực mỗi ngày.

Nói thì dễ hơn làm. Hãy tha thứ cho bản thân và tha thứ cho người khác.

Hãy nhớ: Trước khi tạo yêu cầu kéo (PR), hãy xem xét từ 5 đến 15 yêu cầu kéo khác (hoặc xử lý/kiểm tra từ 5 đến 15 báo cáo lỗi).

Cuối cùng, hãy hiểu giá trị đóng góp của những người có bối cảnh và trình độ kinh nghiệm khác nhau, không chỉ đồng nghiệp hay người quen của bạn. Hãy liên lạc với những người bạn mới (trực tiếp qua tin nhắn IRC cũng được) và hỏi họ cần giúp đỡ gì. Bạn có thể thỉnh thoảng yêu cầu giúp đỡ, nhưng đừng coi đó là quyền lợi của mình. Cho đi nhiều hơn, nhận lại ít hơn.

Thông tin kỹ thuật chi tiết

Đừng tin tưởng hoàn toàn, hãy kiểm chứng. Giảm thiểu sự phụ thuộc vào GitHub trong quá trình xem xét mã nguồn. Chỉ sử dụng trang web GitHub để dữ liệu, chẳng hạn như đọc bình luận và thêm bình luận của riêng bạn — công việc xem xét các commit và mã nguồn nên được thực hiện trên hoàn cảnh cục bộ của bạn.

Tải mã nguồn cho máy cục bộ

Do đó, quy trình xem xét bắt đầu bằng việc tạo một nhánh yêu cầu kéo (PR) cho máy tính của bạn, cho phép bạn biên dịch và xem xét nó cục bộ. Có phương pháp khác nhau tùy thuộc vào ý tưởng, nhu cầu, dung lượng ổ đĩa và băng thông internet của bạn. Dưới đây chỉ là một vài ví dụ:

1. Sử dụng git checkout pr/<number> để kéo một yêu cầu kéo (PR) từ kho lưu trữ từ xa. Như bài viết ngắn gọn này đã nói, bạn có thể sửa đổi nó cho phù hợp với nhu cầu của mình.
2. Phần [remote "origin"] trong cấu hình git của tôi: fetch = +refs/pull/*/head:refs/remotes/origin/pr/*
3. Phiên bản của Luke Dashjr, người đóng góp cho Bitcoin Core: "Để tránh tất cả các nhánh hợp nhất, hãy cấu hình remote origin-pull như sau": fetch = +refs/pull/*/head:refs/remotes/origin-pull/*/head
4. Tài liệu Bitcoin Core: Dễ dàng tham chiếu các yêu cầu kéo (PR) bằng cách sử dụng refspecs
5. Sử dụng pull/<number>/head (nhánh người đóng góp) và pull/<number>/merge (hợp nhất vào nhánh chính), GitHub hiển thị các yêu cầu kéo (PR) dưới dạng các nhánh của mã nguồn gốc, ví dụ: git fetch origin pull/17283/head && git checkout FETCH_HEAD . Tuy nhiên, tôi thường hạn chế tối đa việc sử dụng GitHub.

Bạn có thể kiểm tra PR trên nhánh của người đóng góp hoặc trên nhánh master đã hợp nhất các thay đổi. Việc kiểm tra trên nhánh master rất hữu ích để kiểm tra xem có bất kỳ thay đổi nào được hợp nhất vào nhánh master kể từ lần commit PR cuối cùng gây ra lỗi hay không.

Sau đó, bạn có thể bắt đầu biên dịch và kiểm thử cục bộ đồng thời đọc mã nguồn. Bạn cần phải thành thạo việc biên dịch Bitcoin Core từ mã nguồn và sau đó chạy các bài kiểm thử đơn vị và chức năng , vì bạn sẽ cần kiểm thử nhiều yêu cầu kéo (PR). Do đó, một hướng dẫn về năng suất Bitcoin Core là không thể thiếu.

Hãy đọc và tìm hiểu về Ghi chú dành cho nhà phát triển của Bitcoin Core.

Công cụ so sánh

Trong khi quá trình biên dịch và kiểm thử vẫn đang diễn ra, hãy bắt đầu xem xét từng lần commit mã nguồn trong hoàn cảnh cục bộ của bạn bằng cách sử dụng các công cụ so sánh có thể làm nổi bật sự khác biệt, chẳng hạn như gitk , meld , meld cho macOS , GNU ediff cho Emacs, vimdiff hoặc vim-diffconflicts cho Vim, opendiff trên macOS và diffoscope (đây cũng là hướng dẫn sử dụng các công cụ so sánh ).

Nếu bạn sử dụng gitk và thích chế độ tối, tôi khuyên bạn nên dùng Dracula cho gitk .

Git Grep

Hãy thành thạo việc sử dụng git grep để tìm kiếm trong các kho mã nguồn. Bạn sẽ tiếp tục sử dụng nó cho đến khi tìm thấy tài liệu cần thiết trong kho. Chạy git grep --help trong hoàn cảnh dòng lệnh của bạn để được hỗ trợ.

Nếu bạn không chắc nên bắt đầu từ đâu

Hãy đọc mã nguồn, đọc các bình luận trong yêu cầu kéo (PR), rồi quay lại và đọc lại cả hai. Tìm những phần bạn không hiểu, rồi tự mình tìm hiểu. Lặp lại quá trình này liên tục.

Khi mọi thứ bắt đầu trở nên rõ ràng, hãy chạy bitcoind trên regtest/testnet (hoặc trên mainnet với một khoản phí nhỏ), sau đó theo dõi và tìm kiếm các nhật ký liên quan (chạy bitcoin-cli help logging để biết các danh mục nhật ký bitcoind khác nhau và cách bật/tắt chúng).

Bạn có thể thêm một số logic ghi nhật ký tùy chỉnh, chẳng hạn như LogPrintf hoặc assert ; việc thêm chúng vào mã của người khác là một đặc quyền (để hiểu lý do tại sao, hãy chạy git grep -ni logprintf hoặc git grep asset trong mã nguồn).

Chạy các bài kiểm tra chức năng liên quan và xem lại nhật ký gỡ lỗi. Xác minh rằng cách chúng thất bại trên nhánh chính phù hợp với kỳ vọng. Sau đó, quay lại nhánh PR, đảo ngược hoặc sửa đổi các bài kiểm tra mới để chúng thất bại và tìm hiểu trong đó.

Có lẽ gdb của C++ hoặc pdb của Python (hoặc thêm import pdb:pdb.set_trace() ` vào bất kỳ mã kiểm thử chức năng nào) có thể cung cấp chế độ xem các điểm dừng. Đánh giá. Chạy lệnh RPC.

Kiểm tra xem yêu cầu kéo (PR) có bỏ qua bất kỳ trang gọi hàm, tệp tiêu đề hoặc khai báo nào không.

Hãy thử tái cấu trúc mã nguồn để cải thiện hiệu quả và tìm hiểu lý do tại sao nó không hoạt động. Hãy chuẩn bị tinh thần vì việc này có thể mất gấp đôi thời gian dự kiến. Vâng, đó chính là công việc.

Bạn có thể sử dụng lệnh strace ( man page strace ) để theo dõi các lệnh gọi hệ thống và tín hiệu.

Tùy thuộc vào nội dung của các thay đổi, việc đóng góp các kết quả kiểm tra hiệu năng, phân tích bộ nhớ/Valgrind hoặc biểu đồ flame graph vào quá trình xem xét yêu cầu kéo (PR) đôi khi có thể rất hữu ích, thậm chí mang tính quyết định.

Tài nguyên kỹ thuật

Tôi đã biên soạn một tài liệu chứa nhiều ghi chú kỹ thuật mà tôi thường xuyên tham khảo trong quá trình phát triển Bitcoin Core, và nó nằm ở đây: jonatack/bitcoin-development/notes.txt . Ngoài ra còn có các tài nguyên hữu ích khác trong mã nguồn chứa những ghi chú này. Một nguồn tài nguyên tuyệt vời khác là fanquake/core-review .

gỡ lỗi

Hai tài liệu tóm tắt xuất sắc giải thích cách gỡ lỗi Bitcoin Core:

• " Gỡ lỗi Bitcoin Core ", bởi Fabian Jahr
• " Tìm hiểu sâu và gỡ lỗi Bitcoin Core bằng GDB hoặc LLDB ", bởi Angel Leon

Bổ sung các bài kiểm tra còn thiếu

Ngay cả khi bạn đang xem xét mã nguồn, việc tự viết các bài kiểm thử có thể giúp bạn hiểu cách mã hoạt động và xác minh các thay đổi. Hơn nữa, nếu chúng bổ sung thêm phạm vi kiểm thử hữu ích, bạn có thể đề xuất với tác giả rằng các bài kiểm thử này nên được đưa vào yêu cầu kéo (PR). Đề xuất các bài kiểm thử tự động là một cách rất hữu ích để bắt đầu đóng góp. Các tác giả sẽ đánh giá cao khi ai đó xem xét mã nguồn và cung cấp thêm các bài kiểm thử. Đây là một ví dụ ...

Từ toàn cảnh đến chi tiết nhỏ

Hãy nhớ rằng bức tranh tổng thể quan trọng hơn nhiều so với các lỗi nhỏ, chính tả và quy tắc viết mã. Vui lòng đọc lại phần "Lỗi nhỏ" ở trên. Trong quá trình xem xét, hãy cố gắng tránh bình luận về những điều này, ngay cả khi bạn không có gì khác để bình luận. Tôi biết điều đó khó khăn - bản thân tôi cũng đã từng mắc lỗi này nhiều lần- nhưng có những lựa chọn tốt hơn:

Câu hỏi

Với tư cách là người đánh giá (mà không cần kiến ​​thức chuyên sâu về mã nguồn), một trong những điều tốt nhất bạn có thể làm là đặt câu hỏi . Tác giả của các PR thường rất vui khi được thảo luận về công việc của họ và thấy được sự quan tâm. Vì vậy, hãy dành khoảng 20 phút để xem xét các thay đổi, xác định những phần khó hiểu hoặc không ngờ tới nhất, và sau đó lịch sự đặt những câu hỏi này trong phần bình luận của PR (hoặc trong kênh #bitcoin-core-dev ). Những người khác cũng có thể bị bối rối bởi những vấn đề tương tự, và khi đó vấn đề có thể được làm rõ và ghi lại tốt hơn. Bằng cách này, cả bạn và những người khác đều học được điều gì đó và giúp dự án trở nên dễ hiểu hơn (cảm ơn Russ Yanofsky vì đoạn văn này).

Đánh giá ngang hàng

Hãy đảm bảo bạn đã tìm hiểu và hiểu rõquy trình đánh giá ngang hàng của Bitcoin Core. Quy trình này được cập nhật thường xuyên , vì vậy hãy xem xét lại nó định kỳ.

" ACK " ( nguồn gốc ) thường được sử dụng sau phần mô tả của người kiểm toán về cách họ đã xem xét và kiểm tra thủ công các thay đổi. Là một người đóng góp mới, bạn nên cung cấp mô tả chi tiết hơn về những gì bạn đã làm và suy nghĩ trong phần nhận xét đánh giá để thể hiện sự hiểu biết của bạn về thay đổi.

"Concept ACK" nghĩa là người đánh giá thừa nhận và đồng ý với mục tiêu của thay đổi, nhưng (nhưng chưa) xác nhận đã xem xét hoặc kiểm tra mã. Đây có thể là tín hiệu có giá trị đối với tác giả yêu cầu kéo (PR), cho họ biết rằng PR đó có giá trị và đang đi đúng hướng. Ngược lại, "Concept NACK" cho thấy sự không đồng ý với mục tiêu của PR.

"Phương pháp ACK" tiến thêm một bước so với "Conceptual ACK", nghĩa là nó đồng ý với cả mục tiêu của PR và phương pháp được sử dụng để đạt được sự thay đổi đó. Phương pháp khác, "NACK" thể hiện sự đồng ý với mục tiêu nhưng không đồng ý với phương pháp được sử dụng để đạt được chúng.

Đôi khi người đánh giá bình luận "Code Review ACK" để cho biết rằng mã trông ổn, nhưng họ chưa kiểm tra các thay đổi hoặc chưa hình thành quan điểm ​​về khái niệm đó. Bổ sung thêm bối cảnh sẽ tốt hơn: "Code Review ACK HEAD , chưa rõ mục đích của khái niệm, tôi sẽ xác minh x, y, z," v.v.

Các biến thể ACK khác bao gồm "tACK" hoặc "tested ACK", cho biết ACK đã được kiểm tra, và "utACK" hoặc "untested ACK", cho biết ACK chưa được kiểm tra.

Việc tự mình kiểm thử các tính năng mới hoặc báo cáo sự cố rất được hoan nghênh. Những bình luận như "Đây là kết quả và phương pháp kiểm thử của tôi" rất hữu ích, đặc biệt là khi có thêm chữ "ACK" ở cuối.

Một số yêu cầu kéo (pull request) có thể khó kiểm thử hoặc xác nhận do độ phức tạp, bối cảnh hoặc thiếu khung kiểm thử và mô phỏng. Ví dụ, nếu bạn xem xét kỹ lưỡng mã nguồn và để lại nhận xét như "Mã nguồn có vẻ đúng, nhưng tôi chưa đủ tự tin để xác nhận cách hoạt động của nó", đó cũng là một đóng góp rất có giá trị.

Các bình luận hữu ích khác bao gồm, ví dụ, "đã xác minh phần chỉ di chuyển" đối với các bình luận có chứa "chỉ di chuyển"; và "đang cố gắng tìm hiểu xem việc thay đổi X có thể làm hỏng Y hay không, nhưng không tìm ra kết quả nào (điều này có thực sự xảy ra không?)", v.v.

ACK kèm mã băm gửi

Khi gửi ACK, hãy cho biết trạng thái của mã bạn đang xem xét bằng cách thêm mã băm của commit HEAD (hoặc commit bạn đang xem xét). Cách tiếp cận chính xác và không cần tin tưởng là sử dụng mã băm từ nhánh cục bộ của bạn, chứ không phải từ trang web GitHub. Điều này đảm bảo rằng bạn đang xác nhận các thay đổi cụ thể trừ khi các công cụ cục bộ của bạn bị xâm phạm. Điều này cũng hữu ích khi xảy ra thao tác force push và commit cũ hơn được liên kết đã bị mất trên GitHub.

Một phản hồi ACK hoàn chỉnh sẽ trông như thế này: "ACK fa2f991 , tôi đã biên dịch, chạy các bài kiểm tra, kiểm tra thủ công bằng cách chạy X/Y/Z và xem xét mã. Nó trông ổn và tôi đồng ý rằng nó có thể được hợp nhất."

Tập lệnh hợp nhất Bitcoin Core hiện tại sao chép đoạn văn đầu tiên của mỗi bình luận ACK liên quan đến commit HEAD (tại thời điểm hợp nhất) vào commit đã được hợp nhất. Vì vậy, hãy nhớ rằng, bất cứ điều gì bạn viết vào trong đó sẽ được tập lệnh hợp nhất sao chép và trở thành một phần vĩnh viễn của lịch sử Git.

Một thương vụ PR phức tạp hoặc có rủi ro cao có thể cần ít nhất 3 đến 4 nhà đầu tư giàu kinh nghiệm trước khi có thể được hợp nhất.

Hệ thống bỏ phiếu APACHE

Các quản trị viên của Bitcoin Core thường sử dụng hệ thống bỏ phiếu Apache trong phần bình luận. Đây là một ví dụ .

Hãy khoan dung hơn với người khác.

Hãy xem xét mã nguồn, chứ không phải người đóng góp và các bình luận của họ.

Khi không đồng ý, hãy nêu rõ quan điểm của mình một lần và mãi mãi, rồi tiếp tục. Đây là một ví dụ . Đừng làm ngập tràn phần bình luận bằng lần bài đăng, và đừng hăm dọa hay phản ứng thái quá. Hãy kiên nhẫn, và tránh hung hăng hay bắt nạt. Hãy nhớ rằng, điều quan trọng nhất có thể không phải là vấn đề đang được thảo luận, mà là mối quan hệ của bạn với những người đóng góp khác.

Là một người đóng góp mới, hãy cẩn thận khi đưa ra phản hồi NACK. Điều đó ngụ ý rằng bạn thiếu hiểu biết về bối cảnh. Nếu bạn bắt buộc phải đưa ra phản hồi NACK, hãy cung cấp lý do chính đáng. Đây là một ví dụ .

Gửi bằng chữ ký OpenTimeStamp

Một số người đóng góp cho Bitcoin ký ACK và đính kèm OpenTimeStamp (dấu thời gian mở). Mặc dù điều này nằm ngoài phạm vi bài viết này, việc sử dụng plug-in Git với OpenTimeStamp để ký các commit của bạn khá đơn giản.

Bình luận có thể thu gọn

Sau một thời gian, bạn sẽ nhận thấy rằng đôi khi người đóng góp sử dụng bình luận có thể thu gọn để kiểm duyệt. Điều đó thật tuyệt , bạn có thể tự hỏi, vậy làm thế nào để làm được điều đó ? Nó sử dụng thẻ HTML ` details . Đây là hướng dẫn sử dụng .

Lời cảm ơn

Xin cảm ơn Steve Lee (moneyball) và Michael Folkson đã xem xét bài viết này và đưa ra những góp ý của họ.

Bài viết này nêu bật những nhà phát triển Bitcoin Core xứng đáng nhận được lòng biết ơn của chúng ta, bao gồm các bình luận được ghi nhận trên GitHub và IRC: Wladimir van der Laan, Marco Falke, Pieter Wuille, Gregory Maxwell, Anthony Towns và Russ Yanofsky.

Trong nhiều năm, tôi đã thất vọng về ảnh hưởng của BDFL (Nhà độc tài nhân từ suốt đời) đối với các ngôn ngữ lập trình và các dự án mã nguồn mở. Sự cống hiến lâu dài và khiêm tốn của Wladimir van der Laan cho Bitcoin đã khơi dậy lại niềm đam mê của tôi đối với các dự án mã nguồn mở.

Cuối cùng, tôi xin bày tỏ lòng biết ơn chân thành đến tất cả những người đóng góp cho Bitcoin Core vì sự kiên nhẫn của họ trong việc xem xét các bài nộp của tôi, đặc biệt là John Newbery, Marco Falke, João Barbosa, practicalswift, Gregory Sanders, Jonas Schnelli, Pieter Wuille và Wladimir van der Laan. Tôi cũng xin cảm ơn Adam Jonas và John Newbery vì chỉ dẫn và đề xuất ban đầu của họ.

(qua)