Nếu bạn đã theo dõi quá trình phát triển PostgreSQL trong vài năm qua, bạn có thể đã nghe đến thuật ngữ trình quản lý tệp cam kết một vài lần. Có thể bạn đã biết commitfest là gì, nhưng tại sao lại có trình quản lý? Vì tôi đã dành rất nhiều thời gian vào tháng Giêng vừa qua để quản lý một công ty, tôi sẽ giải thích.
Bản vá được áp dụng trong tệp cam kết
Về cơ bản, bản cam kết PostgreSQL chỉ là một tập hợp các bản vá đang chờ tích hợp vào cơ sở mã PostgreSQL. Nguyên tắc hoạt động của commitfest là mỗi bản vá đã được gửi đến pgsql-hacker phải được xem xét lại kịp thời; sau khi được xem xét và sửa đổi đủ lần, bản vá là ứng cử viên để người cam kết đưa vào PostgreSQL vĩnh viễn.
Đối với dòng công việc commitfest:mỗi bản vá mới bắt đầu cuộc sống trong commitfest ở trạng thái “cần xem xét”; nó có thể được đóng lại là “bị từ chối” (làm tan nát trái tim mong manh của tác giả), “cam kết” (đưa ra ngày, hoặc tuần, hoặc tháng của tác giả), hoặc “trả lại bằng phản hồi” (theo đó tác giả cần giữ lại điều đó, biết những gì để cải thiện bản vá và phục hồi nó trong một bản cam kết trong tương lai). Cũng có một trạng thái tồn tại trong thời gian ngắn, "đang chờ tác giả", được sử dụng để phản hồi nhanh chóng, dự kiến sẽ dẫn đến một phiên bản mới của bản vá sau một vài ngày nữa là "cần xem xét lại". Miễn là chúng tôi có một số điều được đánh dấu là “cam kết” và các tác giả nhận được phản hồi tốt, mọi thứ sẽ tiếp tục phát triển:PostgreSQL phát triển, phát triển và trưởng thành để trở thành “bản phát hành chính” tiếp theo.
Cho đến nay rất tốt.
Tại sao chúng ta cần một người quản lý?
Quản lý một bản kê khai cam kết
Người đọc chú ý có thể nhận thấy rằng có ba nhóm người tham gia vào quá trình này:tác giả bản vá, người đánh giá, người xác nhận. Có rất nhiều sự chồng chéo giữa ba nhóm đó, đó là nơi bắt đầu các vấn đề. Để thực hiện tốt đánh giá cấp mã, mọi người cần hiểu mã và những người làm được cũng đang viết các bản vá lỗi của riêng họ. Mặt khác, những người xác nhận chỉ là những người đánh giá được cho là có khả năng tốt hơn trong việc tìm và sửa các “vấn đề” về mã. Những người cam kết cũng luôn viết các bản vá của riêng họ.
Vấn đề là nếu tác giả bản vá tiếp tục độc quyền làm việc trên các bản vá của họ, họ sẽ không có thời gian để xem xét hoặc cam kết các bản vá của người khác. Điều này có thể dễ dàng xảy ra nếu họ nhận được phản hồi và ngay lập tức làm việc trên một phiên bản khác dẫn đến nhiều phản hồi hơn; điều này tạo ra một vòng lặp có thể kéo dài rất lâu. Tại một số điểm, điều hợp lý cần làm là tác giả loại bỏ bản vá khỏi bản cam kết và làm việc để xem xét bản vá của người khác; nhưng vì mọi người đều tin rằng các bản vá của họ là rất quan trọng, điều này hiếm khi xảy ra một cách tự phát.
Đó là nơi mà trình quản lý tệp cam kết nhập vào bức tranh. Một nhiệm vụ là thu hút sự quan tâm từ những người tin tặc pgsql vào việc thực sự xem xét các bản vá. Hầu hết thời gian, gửi email công khai cho nhóm là đủ để mọi người đọc, thảo luận, thử nghiệm và suy nghĩ về các bản vá. Thông thường, các tác giả bản vá cần được nhắc nhở rằng họ cần xem xét các bản vá của người khác, không chỉ của riêng họ. Ứng dụng commitfest có giao diện gửi email tiện dụng có thể được sử dụng cho việc đó. Những điều này thường đủ để tạo ra một lượng đánh giá chéo tốt.
Có một quy tắc cũ gần như bị lãng quên:nếu tác giả bản vá không thực hiện đánh giá, các bản vá của họ có thể bị đóng khỏi bản cam kết mà không cần xem xét thêm. Theo hiểu biết của tôi, điều này chưa bao giờ xảy ra, điều này chứng tỏ rằng ít nhất ở một mức độ nào đó, các tác giả bản vá đang là “công dân tốt”.
Do đó, bằng cách thuyết phục hoặc ép buộc, người quản lý cam kết có thể khiến mọi người xem xét các bản vá, điều này hầu như sẽ không xảy ra một cách tự phát trừ khi tin tặc đã hợp tác.
Mặt khác, các tác giả bản vá đôi khi để các bản vá của họ kéo dài mà không có bản cập nhật. Một câu trả lời khả thi là chỉ cần đóng chúng lại "được trả lại với phản hồi", nhưng phần lớn thời gian, điều này đáng khuyến khích tác giả gửi phiên bản cập nhật.
Người quản lý tệp cam kết cũng có thể dành nhiều thời gian để thực hiện đánh giá của riêng họ và nếu họ có đặc quyền cam kết, hãy cam kết các bản vá.
Cuối cùng, trách nhiệm của người quản lý tệp cam kết là đảm bảo tất cả các bản vá được đóng khi tệp cam kết kết thúc, thông thường sẽ sau một tháng kể từ khi bắt đầu. Đối với các bản vá đã nhận được phản hồi mà tác giả đã phản hồi bằng một phiên bản khác, nên “chuyển bản vá sang bản cam kết tiếp theo” là điều hoàn toàn hợp lý:lời hứa của bản cam kết (đưa ra phản hồi) đã được giữ nguyên. Tuy nhiên, làm điều đó với các bản vá chưa nhận được bất kỳ phản hồi nào là không công bằng. Việc đóng các cam kết trở nên khó khăn hơn khi điều đó xảy ra.
Bản cam kết tháng 1 năm 2016
Biểu đồ này minh họa cam kết tháng 1 năm 2016. Dữ liệu là từ các email trạng thái hàng tuần mà tôi đã gửi:bắt đầu, tuần 1, tuần 2, tuần 3, tuần 4, cuối cùng.
Bạn có thể thấy rằng chúng tôi bắt đầu với 85 ở trạng thái “cần xem xét” hoặc “sẵn sàng cho người cam kết”, nghĩa là họ đang chờ ai đó khác ngoài tác giả hành động. Một tuần sau, chúng tôi đã nhận được 71 bản vá cho các trạng thái đó:điều đó có nghĩa là 14 bản vá được xử lý trong một tuần, điều này không tệ bởi vì nếu duy trì, tỷ lệ đó có nghĩa là toàn bộ hàng đợi bản vá sẽ kết thúc chỉ trong 5 tuần nữa.
Tuy nhiên, trong tuần đầu tiên đó, tôi đã phạm phải sáu bản vá nhỏ. Những thứ đó hết khá nhanh và tỷ lệ cam kết dự kiến sẽ giảm. May mắn thay, những người cam kết khác đã làm việc chăm chỉ và bạn có thể thấy rằng tỷ lệ các bản vá được cam kết là không đổi trong suốt thời gian. Có lẽ có thể đạt được điều này trong tất cả các cam kết, giả sử áp dụng sự thuyết phục thích hợp cho những người cam kết.
Có thể thấy rằng trạng thái "được trả lại với phản hồi" chỉ xuất hiện ở cuối tệp cam kết. Nó gần như tiếp tục xu hướng được thấy trong dòng "chờ tác giả". Theo tôi, điều này là ổn. Một số người muốn các bản vá lỗi nhất định được “khởi động” sớm, để các nỗ lực tập trung vào các bản vá lỗi thực sự có cơ hội tham gia (một “bộ ba”, nếu bạn muốn). Bản thân tôi cũng không chắc về điều đó nên tôi không áp dụng ý tưởng đó ở đây.
Tôi nghĩ rằng bản cam kết này đã thành công vừa phải trong việc nhận được các bản vá lỗi được cam kết; những tiến bộ trong mặt trận đó chắc chắn đã có thể nhìn thấy được, nếu không nhất thiết là rất lớn. Tôi cũng nghĩ rằng nó đã rất thành công trong việc đảm bảo rằng mọi tác giả bản vá đều có được một số lượng thảo luận hợp lý về các bản vá của họ. Vì vậy, về phần mình, tôi hài lòng với công việc đã hoàn thành.
Lời khuyên cho những người quản lý bản cam kết trong tương lai
Tôi nghĩ rằng việc cập nhật trạng thái hàng tuần sẽ mang lại kết quả tốt:nó mang lại cho mọi người ấn tượng rằng điều gì đó đang xảy ra (chính là như vậy), thúc đẩy cả người đánh giá và người cam kết thực hiện công việc của họ.
Ngoài ra, tôi thực hiện phương pháp liệt kê một số bản vá lỗi cần chú ý mỗi lần - không phải các bản vá lỗi giống nhau mọi lúc, mà thay vào đó, tôi tập trung vào một tập hợp khác nhau mỗi lần, để đảm bảo rằng mọi bản vá lỗi bị đình trệ đều có một cú hích ở đâu đó. Đây là một công việc tinh tế:sẽ dễ dàng hơn nếu chỉ liệt kê tất cả các bản vá lỗi cần chú ý, nhưng nếu bạn làm điều đó, đôi mắt sẽ nhìn chằm chằm vào các danh sách khổng lồ và mọi thứ tiếp tục bị bỏ qua.
Bất kỳ ý kiến nào của bạn về cách quản lý bản cam kết sẽ được đánh giá cao; vui lòng gửi email cho tôi nếu bạn không muốn đăng nó công khai dưới dạng nhận xét. Nếu bạn cho rằng những việc tôi đã làm không hiệu quả hoặc nếu bạn có ý tưởng khác về việc phải làm, tôi sẵn sàng lắng nghe. Tôi có thể quản lý các cam kết khác trong tương lai, nếu tài nguyên cho phép.
Cuối cùng, hãy chuẩn bị tinh thần cho hành trình cam kết tháng 3 năm 2016 sắp tới. Đây sẽ là bản cam kết cuối cùng cho ngày 9.6 và tôi chắc chắn rằng sẽ có rất nhiều việc phải làm cho mọi người. Chúc bạn xem lại bản vá vui vẻ!
