Quản lý một Bản cam kết PostgreSQL khác

Tôi đã viết về cách quản lý một bản cam kết PostgreSQL trước đây.

Trong chu kỳ phát triển PostgreSQL 13, tôi đã thực hiện lại. Lần này tôi sử dụng một chiến lược khác, chủ yếu là vì tôi cảm thấy rằng có sự tích tụ quá nhiều các bản vá lỗi rất cũ mà không được chú ý đầy đủ. Vì vậy, ngoài các bản sửa lỗi (luôn là những trường hợp đặc biệt), tôi tập trung vào các bản vá đã nằm trong hàng đợi lâu hơn.

Một điều tôi nhận thấy là một số bản vá đã không được cập nhật theo phản hồi, hoặc theo sự mục nát của bit, ngay cả sau khi lặp đi lặp lại việc thúc đẩy từ các nhà quản lý tệp cam kết trước đó. Họ chuyển từ bản cam kết này sang bản cam kết khác mà không có hoạt động nào khác. Một số trong số đó là từ những người đã chuyển sang phát triển PostgreSQL; những người khác có thể là dự án bị bỏ rơi. Theo tôi, chẳng ích gì khi giữ chúng lại nếu không có gì xảy ra, vì vậy tôi đã đóng chúng lại và cung cấp một danh sách, để những người khác có thể xem và nắm quyền sở hữu nếu họ muốn. (Một bài đăng tiếp theo chứa một số khác). Tôi hy vọng rằng nếu ai đó quan tâm đến những tính năng đó, họ sẽ chọn các bản vá và gửi lại sau khi giải quyết bất kỳ phản hồi nào và bit-rot.

Một điều khác đang trở nên phổ biến là nhiều bản vá lỗi kéo dài với ít đánh giá - hoặc đôi khi thậm chí với đánh giá đáng kể, chúng không bao giờ đạt được điểm mà người cam kết chọn chúng. Trong một số trường hợp đó, cách tiếp cận của tôi là khuyến khích những người cụ thể mà tôi nghĩ có thể giúp ích cho việc xem xét; trong các trường hợp khác, tôi chỉ tự mình xem xét các bản vá. Đôi khi, chỉ cần đặt một câu hỏi dường như đã đủ để thu hút những người khác tham gia vào cuộc thảo luận, vì vậy ngay cả khi đóng góp trực tiếp của một người là nhỏ, nó có tác dụng hữu ích lớn hơn.

Bản thân tôi cũng đã đăng ký làm người đánh giá / người cam kết cho một số bản vá. Tôi đã thành công ở mức độ vừa phải, kết thúc với 24 lần cam kết và 10 mục nhập tệp cam kết được đánh dấu là đã cam kết… hoặc khoảng 25% tổng số mục nhập tệp tin cam kết được cam kết. Không tệ phải không?

Trong email báo cáo đóng cửa của mình, tôi đã đăng bảng này:

Một điều đáng chú ý là mức độ "được trả lại với phản hồi" ở mức khá thấp trong suốt thời gian và chỉ tăng lên vào cuối cùng, và khá lớn. Một bài tập mà tôi đề nghị các CFM trong tương lai nên làm là đóng các bản vá lỗi bit-rot không hoạt động một cách lành mạnh vào cuối nhiệm vụ của họ, thay vì chuyển các bản vá như vậy sang bản cam kết tiếp theo. Thao tác thứ hai nên được dành riêng cho các bản vá đã hoạt động trong thời gian diễn ra CF, hoặc những bản vẫn còn áp dụng, hoặc những bản chỉ được tác giả chờ đợi trong thời gian gần đây. Một điều đáng chú ý khác là số lượng các bản vá được cam kết… hay đúng hơn là nó tăng chậm như thế nào. Một số người cam kết đã bị phân tâm bởi giúp Postgres 12 được phát hành; những người khác đã rất tích cực trong các bản vá mà không một phần của cam kết. Tôi hy vọng rằng một số người cam kết sẽ chú ý hơn vào thời gian tới và sau đó chúng ta sẽ thấy một số tiến bộ thực tế.

Bot cam kết của Thomas Munro là một công cụ vô giá; tác giả vá nên chú ý nhiều hơn đến điều đó. Sẽ tốt hơn nhiều nếu dịch vụ đó được tích hợp vào cơ sở hạ tầng cam kết cộng đồng của chúng tôi; Tôi nghĩ rằng điều đó chỉ cần một số trang phục chỉnh chu.

Một số thứ mà tôi muốn có:

• pg_dump được cập nhật của dữ liệu bản kê khai, để truy vấn cục bộ.
• Tôi đã nhận được kết xuất hàng tuần bằng cách hỏi đúng người và viết một số truy vấn thô. Có lẽ chúng tôi có thể cung cấp kết quả của (các phiên bản cải tiến của) các truy vấn như báo cáo trong ứng dụng.
• Một số tính năng lọc được cải thiện trong ứng dụng commitfest cũng sẽ được hoan nghênh.
• Hành động di chuyển các bản vá en masse để CF tiếp theo có thể được tự động hóa tốt hơn.

Nói chung, đây là một tháng rất hài lòng và tôi hy vọng nó có giá trị cho sự phát triển của PostgreSQL. Tôi rất biết ơn vì 2ndQuadrant đã cho tôi cơ hội dành cả tháng để làm việc này… nhưng ngay cả như vậy, tôi vẫn mong được trở lại với nhiệm vụ thường xuyên của mình.