1 điểm bởi GN⁺ 3 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Guix đã chuyển cách cộng tác vốn vận hành hơn 10 năm trên Savannah và Debbugs dựa trên email sang Codeberg vào năm 2025, qua đó thay đổi lớn điểm vào đóng góp của một dự án có hơn 400 người tham gia mỗi năm
  • Việc chuyển đổi là trường hợp áp dụng thực tế đầu tiên của quy trình Guix Consensus Document được đưa vào từ tháng 12/2024, và GCD 002 có hiệu lực vào đầu tháng 5/2025 sau hai tháng thảo luận
  • Quy trình làm việc bằng email trước đây vẫn hiệu quả với người dùng thành thạo nhờ các công cụ như Emacs, mumi và qa.guix.gnu.org, nhưng trong khảo sát với 900 người phản hồi, nó thường bị nêu là một rào cản đối với người đóng góp
  • Sau khi chuyển sang Codeberg, số tác giả và số tác giả mới đều tăng, nhưng nếu bỏ qua đỉnh tạm thời vào tháng 6/2025 thì khó xác nhận một hiệu ứng Codeberg rõ rệt
  • Mỗi tháng có hơn 500 pull request được mở và backlog đang phình to, nên việc giảm khoảng trống CI, yêu cầu chữ ký và gánh nặng review vẫn là bài toán vận hành tiếp theo của Guix

Chuyển từ cộng tác qua email sang Codeberg

  • Guix đã chuyển lưu trữ mã nguồn, theo dõi issue và pull request sang Codeberg trong năm 2025
    • Trước đó, dự án lưu trữ mã trên Savannah suốt hơn 10 năm
    • Báo lỗi và patch được xử lý qua email và theo dõi bằng phiên bản Debbugs
    • Đây là thay đổi lớn vì mỗi năm có hơn 400 người đóng góp mã cho dự án
  • Các cộng tác viên cốt lõi trước đây đã quen với quy trình email và làm việc hiệu quả bằng gói Debbugs cho Emacs hoặc các email client nâng cao
    • Debbugs dựa vào vài trăm dòng mã Perl cùng các tiêu chuẩn email và cấu trúc liên hợp, trong khi các web forge như Forgejo là hệ thống lớn hơn với nhiều phụ thuộc Go
  • Xung quanh luồng email cũ cũng đã có sẵn các công cụ hỗ trợ
    • mumi cung cấp giao diện web cho Debbugs
    • Quality Assurance service tự động áp dụng chuỗi patch gửi qua email lên nhánh Git và build package từ nhánh đó
  • Khảo sát đầu tiên dành cho người dùng và người đóng góp được công bố vào tháng 1/2025 đã nhận hơn 900 phản hồi, và những người đóng góp thường nêu quy trình email là rào cản khi tham gia

Quyết định dựa trên đồng thuận qua GCD 002

  • Guix không có một “benevolent dictator” để đưa ra quyết định, nên vào tháng 12/2024 đã đưa vào quy trình Guix Consensus Document
  • Quy trình GCD hướng tới xây dựng đồng thuận thay vì chỉ bỏ phiếu đơn thuần
    • Người đề xuất phải cùng những người tham gia điều chỉnh đề xuất
    • Người tham gia không chỉ phản đối mà còn phải nêu nhu cầu của mình và đề xuất thay đổi cụ thể để phản ánh điều đó
    • Ở bản cuối, mọi người thể hiện lập trường bằng support, accept, disapprove
  • GCD 002 được gửi vào tháng 2/2025 như đề xuất chuyển sang Codeberg
    • Thảo luận diễn ra trong hai tháng, tức thời lượng tối đa theo quy trình
    • Hai phần ba thành viên nhóm Guix đã tham gia cân nhắc
    • Trong số người tham gia, 72% chọn support, 28% còn lại chọn accept
    • Không có ai chọn disapprove, và đề xuất có hiệu lực vào đầu tháng 5/2025
  • Một số thành viên gắn bó lâu năm cảm thấy quy trình có vẻ ưu tiên web này kém hiệu quả hơn email, đồng thời không thích việc từ bỏ một phần hạ tầng dựa trên email
  • Khả năng tạo thêm điểm tiếp xúc với cộng đồng rộng hơn và cải thiện trải nghiệm lập trình viên là yếu tố ủng hộ việc chuyển đổi
  • Việc ưu tiên một forge phần mềm tự do và được vận hành bởi tổ chức phi lợi nhuận Codeberg e.V. không gây tranh cãi lớn và cũng phù hợp với định hướng của Guix

Chuyển đổi từng bước và khoảng trống CI lớn hơn dự kiến

  • Việc chuyển sang Codeberg được triển khai từng bước đúng như đồng thuận trong GCD
    • Kho mã chính được di chuyển vào ngày 25/5/2025
    • Kho cũ hiện vẫn được giữ làm mirror
    • Bộ theo dõi issue và patch cũ sẽ được duy trì đến ngày 1/1/2026
    • Sau đó, issue và pull request trên Codeberg sẽ là cơ chế hỗ trợ duy nhất
    • Các báo lỗi và patch trước đây vẫn có thể truy cập trực tuyến
  • Nhờ kế hoạch được xây dựng trong quá trình thảo luận đồng thuận, khi chuyển đổi có ít sự cố lớn hay tình huống ngoài dự kiến
  • Chất lượng dịch vụ từ nhân viên và tình nguyện viên của Codeberg e.V. là tốt, và các lần downtime gián đoạn thường ngắn và được thông báo rõ ràng
  • Với những người đóng góp thích quy trình ngoài trình duyệt, việc cải thiện giao diện Emacs đã giúp ích
  • Vấn đề chưa được dự đoán đầy đủ là tích hợp liên tục cho pull request
    • Tính năng build patch email trên qa.guix.gnu.org đã không được chuyển sang Codeberg
    • Trong vài tháng, reviewer phải tự kiểm tra xem pull request có gây vấn đề hay không, và đây không phải trạng thái bền vững
  • Đến tháng 9/2025, một phiên bản Cuirass được dựng tại pulls.ci.guix.gnu.org để bắt đầu build pull request
    • Ban đầu nó bị xem là giải pháp tạm thời vì còn nhiều hạn chế hơn qa.guix.gnu.org
    • Hiện tại package chỉ được build cho một kiến trúc duy nhất
    • Người đóng góp mới có thể thấy ngay kết quả thành công hoặc thất bại do guix-cuirass-bot để lại trên pull request

Luồng đóng góp tăng nhưng backlog cũng phình ra

  • Nếu nhìn theo số commit lên nhánh chính từ tháng 5/2024 đến tháng 5/2026, tốc độ commit của Guix liên tục nằm giữa mức “cao” và “rất cao”
  • Chỉ nhìn tốc độ commit thì khó thấy thay đổi, nên số tác giả commit theo tháng, số committer và số tác giả mới theo tháng là các chỉ số hữu ích hơn
  • Số tác giả theo tháng và số tác giả mới tiếp tục tăng
    • Ngay sau khi chuyển sang Codeberg, vào tháng 6/2025, cả số tác giả lẫn số tác giả mới đều đạt đỉnh
    • Ngoài giai đoạn đó, tăng trưởng của giai đoạn 2025–2026 khá giống với giai đoạn 2024–2025
    • Guix vẫn tiếp tục thu hút người đóng góp mới, nhưng hiệu ứng Codeberg rõ rệt thì không lớn
  • Mức tăng số committer theo tháng chậm hơn mức tăng số tác giả, điều này có thể cho thấy các committer đang xử lý nhiều đóng góp hơn
  • Dữ liệu pull request được thu thập qua Forgejo API của Codeberg
  • Mỗi tháng có hơn 500 pull request được mở và tốc độ merge cũng cao, nhưng vẫn thấp hơn một chút so với lượng đổ vào nên backlog tiếp tục tăng
    • Hiện có khoảng 639 pull request đang mở trên tổng số 6.459, tức gần 10%
    • Để so sánh, Nixpkgs có khoảng 12k pull request mở trên tổng 473k, tức khoảng 2,5%
    • Backlog của Guix có thể đến từ ma sát quá lớn hoặc phản hồi CI chưa đủ
  • Guix yêu cầu mỗi commit phải có chữ ký của committer đã được phê duyệt
    • Đây không phải kiểu chỉ bấm nút Merge như nhiều dự án khác, bao gồm cả Nixpkgs
    • Người merge phải chịu trách nhiệm áp dụng thay đổi và ký
    • Guix chọn bảo mật chuỗi cung ứng phần mềm giữa sự tiện lợi cho lập trình viên và an toàn cho người dùng
    • Việc có thể giảm chi phí này hay không vẫn còn phải kiểm chứng

Cộng tác trở nên dễ nhìn thấy hơn trên Codeberg

  • Sau khi chuyển sang Codeberg, hoạt động của dự án trở nên dễ quan sát hơn
  • Kết quả CI hiển thị trực tiếp trong pull request để người đóng góp có thể kiểm tra ngay
  • Các nhóm của Guix được triển khai thành team trên Codeberg
    • Phạm vi của từng team được nêu trong tệp CODEOWNERS
    • Người phụ trách phạm vi tương ứng sẽ được gọi tự động
    • Bot gắn các nhãn như team-python để có thể lọc issue và pull request theo label
  • Vấn đề team không nhận được thông báo từ issue có gắn nhãn đó vẫn là một điểm bất tiện
  • Các tính năng như tham chiếu chéo giữa issue và pull request, hay milestone, cũng có vẻ giúp ích cho cộng tác

Những bài toán hạ tầng còn lại và quan hệ với Codeberg

  • Hạ tầng của Guix vẫn cần thêm hỗ trợ
    • Cần nâng hiệu năng build của pulls.ci.guix.gnu.org
    • Sẽ tốt hơn nếu có thể build cả các kiến trúc không phải x86
    • Cuirass vẫn có nhiều giới hạn, và một phần đang được xử lý trong dòng 1.4.x dự kiến
    • pulls.ci.guix.gnu.org hiện vẫn chủ yếu xoay quanh package, nhưng sẽ tốt nếu có thể chạy cả system test khi phù hợp
  • Quy trình làm việc của packager cũng còn chỗ để cải thiện
  • Guix cần tránh gây tải quá mức lên máy chủ Codeberg và cũng phải theo dõi mức sử dụng kho lưu trữ
  • Một giải pháp là yêu cầu người đóng góp mới dùng AGit workflow để tạo pull request
    • AGit vốn đã phổ biến trong cộng đồng đóng góp của Guix
    • Tuy vậy, với một số người nó vẫn kém quen thuộc hơn quy trình pull request thông thường nên bị xem là một “downgrade”
    • Như trường hợp Gentoo, việc thêm biểu tượng “AGit fork” có thể giúp tăng khả năng được tìm thấy
  • Guix Foundation đã bỏ phiếu trở thành thành viên hỗ trợ của Codeberg e.V. như một cách bày tỏ sự cảm ơn và ủng hộ
  • Một pull request bổ sung Forgejo và dịch vụ để cấu hình nó trong Guix đã được gửi lên
    • Đây là hướng đi để việc cấu hình khai báo và triển khai forge có thể tái lập trở nên khả thi ngay trong Guix

1 bình luận

 
Ý kiến trên Lobste.rs
  • Thật sự rất thú vị khi nhìn vào các chỉ số dự án thực tế liên quan đến việc chuyển sang Codeberg. Cá nhân tôi có quá nhiều lý do để rời GitHub nên hy vọng Codeberg sẽ trở thành GitHub mới, nhưng tôi đã chuyển sang máy chủ Forgejo tự quản lý và hiện dùng Codeberg làm nơi sao lưu cho toàn bộ kho lưu trữ

    • Dù hiểu đây là ý tốt, tôi nghĩ sẽ tốt hơn nếu thay vì mọi thứ dồn về Codeberg, sẽ có nhiều forge độc lập giao tiếp với nhau qua ForgeFed
      Chúng ta không cần thêm một trung tâm mới xoay quanh mã nguồn mở nữa
    • Hiện tại tôi không nghĩ Forgejo đã đủ khả năng mở rộng để đảm nhận vai trò đó. Phía Codeberg đang làm trong khả năng của họ và tôi hy vọng mọi thứ sẽ cải thiện, nhưng có lẽ sẽ mất thời gian
    • Cuối cùng thì mọi việc cá nhân tôi làm đều đã chuyển sang Fossil, và với những gì muốn công khai cho người khác, tôi đã dựng máy chủ Fossil riêng
      Cho tới nay mọi thứ rất tốt và tôi rõ ràng thích nó hơn git. Theo tiêu chuẩn ngày nay thì rào cản đó không quá cao, nhưng vẫn có
  • Điều thực sự khiến tôi khó chịu sau khi bắt đầu dùng Codeberg là hầu như không có công cụ nào hỗ trợ tích hợp git cho ra hồn, và phần lớn trên thực tế chỉ dành cho GitHub / GitLab

    • Ở góc độ người dùng magit forge thì đúng là muốn khóc
  • Tôi không hiểu đoạn nói rằng họ sẽ duy trì trình theo dõi issue·patch cũ đến ngày 1 tháng 1 năm 2026, sau đó chỉ còn hỗ trợ issue và pull request trên Codeberg
    Nếu một phần đáng kể cộng tác viên không thích luồng làm việc mới thì tôi không hiểu vì sao lại ép buộc thay đổi như vậy, và tôi cũng tò mò không biết việc cho phép nhiều luồng làm việc khác nhau có chi phí ẩn nào không. Tôi nghi ngờ việc tại sao phải ép tất cả mọi người dùng cùng một cách
    Dù chỉ là soi mói nhỏ, tôi không nghĩ Codeberg có nhiều nhân viên được trả lương; theo tôi biết thì chỉ có một người. Đính chính: tháng 12 năm ngoái họ đã bổ sung nhân viên thứ hai.