- Người dùng Jujutsu và các hệ thống quản lý phiên bản khác đang bàn về các quy trình làm việc Git thuần túy mà những forge lớn chưa hỗ trợ đầy đủ
- Mối quan tâm cốt lõi không phải là cách triển khai như SPA/JS hay HTML render phía máy chủ, mà là cách kho lưu trữ biểu đạt và vận hành các chức năng quản lý phiên bản
- Có những ý tưởng như Tangled, stacked PRs của GitHub, hay forgefed, nhưng rất khó tìm được một nơi tập hợp ý kiến người dùng về thiết kế
- Bao gồm cả stacked PR/MR và các mô hình cộng tác thay thế; trải nghiệm quản lý phiên bản vượt ra ngoài các forge hiện có là điểm tranh luận chính
- Việc hiển thị các đối tượng kho lưu trữ như tag, commit, tree, blob nhìn chung khá giống nhau giữa các forge, và hầu như không có thảo luận nào ngoài khác biệt định dạng nhỏ
1 bình luận
Ý kiến trên Lobste.rs
Tôi sẽ không bao giờ dùng bình luận review code nếu chúng không là một phần của chính kho mã
Về bản chất, việc lưu trữ ngữ cảnh lịch sử có giá trị trong mailing list, silo cơ sở dữ liệu, hay một lớp tách biệt không được ghim vào hash commit HEAD cũng mang cùng loại rủi ro như GitHub
Fossil có đi theo hướng này phần nào nhưng mới chỉ xử lý issue, còn review code thì vẫn theo kiểu patch qua email: https://fossil-scm.org/home/doc/tip/www/contribute.wiki
Một khi thông tin này nằm trong hệ thống quản lý phiên bản, ta có thể dựng lên trên đó một web UI đẹp, feed RSS, và mailing list
Tính năng thứ hai là hỗ trợ tích hợp sẵn merge queue. Với các dự án không tầm thường, từng người đóng góp riêng lẻ không nên push thẳng vào nhánh main; thay vào đó, khi một commit cụ thể được đánh dấu là “sẵn sàng tích hợp”, bot nên tuần tự hóa các thay đổi được đề xuất, lên lịch CI một cách tối ưu, và đẩy main tiến lên bằng một hash đã được xác minh
Tính năng thứ ba là CI đóng vai trò bộ thực thi công việc cách ly trên các môi trường dị thể như Windows, macOS, v.v.: https://gregoryszorc.com/blog/2021/…
Bất kỳ ai cũng nên có thể tạo tài khoản và mở issue, nhưng không nên có spam
Hiện GitHub làm điều này khá tốt. Thỉnh thoảng tôi vẫn thấy spam, nhưng sau khi báo cáo lạm dụng thì nó bị gỡ rất nhanh. Có lẽ phía sau là sự kết hợp giữa tự động hóa kiểu “máy móc” và đội phân loại do người thật vận hành
Tôi đang xem Fossil như một “forge” cho dự án cá nhân, và có lẽ sẽ không có nhiều người đóng góp bên ngoài, nên review code chỉ là thứ có thì tốt
Thay vào đó, tôi muốn một SQLite DB có thể đồng bộ, gửi đi, và truy vấn tùy ý
Đợt refactor lớn tiếp theo tôi muốn làm trong git-pr là phơi bày SQLite DB qua lệnh SSH:
ssh pr.pico.sh sqlSQLite có mặt ở khắp nơi đủ để dùng và rất đa dụng, nhưng lại thiếu trải nghiệm tiện dụng khi được xem như một phần của forge
Tuy vậy, với trường hợp lịch sử bị viết lại như force-push hay squash merge, tôi tự hỏi về sau các bình luận đó sẽ được “ghim” vào đâu để người dùng còn tìm thấy
Trên GitHub, mốc neo đó là Pull Request, nên bạn vẫn xem được thảo luận dù các commit bên trong đã thay đổi
Tôi đang tự hỏi liệu hệ thống này cũng sẽ có một khái niệm PR riêng được lưu trong kho, hay là kỳ vọng một thứ gì đó tích hợp chặt chẽ hơn
Dù vậy, vì tôi dùng
jjkhá ổn nên trên thực tế có thể đây không phải vấn đề lớnSau khi dùng cả Gerrit lẫn email, tôi thấy tiếc khi mô hình pull request lại thống trị đến vậy
Đặc biệt là khi người bảo trì có thể tự sửa những góp ý nhỏ về style thay vì để lại bình luận, còn người đóng góp thì có thể chẳng quá quan tâm đến các chi tiết style đó
Nhưng điều đáng tiếc hơn là với Darcs hay Pijul, thứ ngày nay tôi dùng ngày càng nhiều, lại hoàn toàn không có workflow nào ngoài email
Tôi muốn thứ gì đó dựa trên XMPP thay cho email. Nó có thể cho phép cộng tác phân tán theo thời gian thực trên patch đang làm, thậm chí có thể một MUC cho mỗi patchset
MUC có thể được mở như voice chat, và các tính năng như vai trò, tệp đính kèm, reaction, tìm kiếm, MAM, điều phối, hay tombstoning sau khi hoàn tất đều đã được định nghĩa trong XEP
Có thể dùng PubSub cho việc đăng ký theo dõi, và cũng tận dụng làm phương tiện chuyển CI
Để thực dụng thì sẽ cần client chuyên dụng, nhưng nhiều tính năng có thể cứ thế hoạt động trên bất kỳ client nào
Thực tế, có lẽ đây gần như chỉ là việc gần đây tôi bị cuốn hút bởi cách các công nghệ liên hợp cũ bất ngờ được mở rộng
Review code và phê duyệt là nút thắt cổ chai
Việc giao tiếp với người gửi code có độ trễ rất lớn, đôi khi mất hàng tuần hay hàng tháng, và độ tin cậy cũng thấp. Có người mở PR rồi biến mất
Mô hình GitHub dựa trên giả định có tương tác qua lại hoàn toàn sụp đổ ở đây
Sẽ tốt nếu trong lúc review có thể trực tiếp sửa code và amend commit kiểu như
git-absorb. Việc qua lại chỉ vì những lỗi nhỏ như typo là lãng phí thời gian, còn kiểu “Edit Suggestion” trên GitHub thì phiền phức và làm lịch sử lộn xộnTôi không muốn phải review lại cùng một đoạn code. Nếu chỉ có vấn đề ở một hàm hay một commit thì phần còn lại nên có thể được phê duyệt trước, và khi người gửi sửa bằng force-push thì không cần xem lại mọi thứ
Sẽ tốt nếu có thể merge chỉ một phần PR, hoặc loại bớt commit mà không cần đóng PR. Có những lúc bản thân tính năng không đáng lấy, nhưng phần nền tảng bên dưới vẫn đáng giữ lại; ngược lại, đôi khi lại chen vào những “dọn dẹp” hay định dạng lại không cần thiết
Khi tác giả gốc không phản hồi, người khác nên có thể cộng tác trên PR, tinh chỉnh và giải quyết vấn đề. Trong mô hình GitHub về lý thuyết cũng làm được, nhưng trên thực tế gần như là một bí kíp ẩn kiểu tạo PR cho một PR khác, và code lẫn thông báo đó không hiện ra ở dự án đích. Mọi người fork rồi mở PR sửa tiếp thì chỉ tạo thêm rối rắm và xung đột merge
Nhiều khi code được gửi lên nhìn chung là ổn nhưng tôi vẫn muốn vài cải thiện nhỏ. Từ phía người gửi, sẽ rất khó chịu khi cảm giác PR bị giữ làm con tin cho đến khi mọi phần hoàn thiện cuối cùng đều xong; còn từ phía người bảo trì, nếu merge ngay thì có nguy cơ người gửi biến mất và các cải thiện tiếp theo sẽ chẳng bao giờ xảy ra. Sẽ tốt nếu có cách merge tạm thời kèm nghĩa vụ dọn dẹp sau. Ví dụ, có thể merge vào nhánh staging nhưng không cherry-pick sang nhánh stable cho tới khi FIXME được giải quyết
Ở các dự án mã nguồn mở phổ biến, có thể chỉ có 1 người đủ quyền review code và phê duyệt để đẩy dự án tiến lên, trong khi có tới 500 người muốn đóng góp và giúp đỡ lẫn nhau. Mô hình GitHub hoàn toàn không tận dụng được lượng năng lực đóng góp dư thừa này. Thay vì hỗ trợ cộng tác, nó biến mọi thứ thành khủng hoảng, hỗn loạn, và áp lực đám đông đầy giận dữ. Cần hỗ trợ tốt hơn cho việc quản lý fork và sao chép code giữa các fork để người khác có thể thử nghiệm và thúc đẩy dự án mà không bị mắc kẹt bởi một người bảo trì duy nhất; đồng thời người bảo trì cũng nên dễ dàng chọn ra những thay đổi phổ biến và đã được kiểm chứng hoạt động từ nhiều fork khác nhau
Trong tổ chức thì hình như đây từng là mặc định, nhưng dù sao trong trường hợp đó bạn có thể dọn dẹp trực tiếp bằng force-push khá gọn
Tôi luôn làm vậy với các chỉnh sửa nhỏ không đáng để qua lại
Thường cảm giác được đo bằng tháng hoặc năm
Thỉnh thoảng tôi cũng là maintainer, và tôi thừa nhận mình cũng không phải lúc nào nhanh hơn mốc đó
Tôi muốn có các chức năng như đi tới định nghĩa, popup hover hiển thị chữ ký hàm hay doc comment
Tất nhiên có thể checkout nhánh và review trong trình soạn thảo mình thích, nhưng như đã nói, review chính là nút thắt
Khi phải review nhiều PR, công việc phụ thêm vì cứ phải đổi qua lại giữa các nhánh là quá lớn
Cần có một người dùng duy nhất, hoặc ít nhất là chế độ một người dùng
Tại sao tôi phải chấp nhận URL kiểu https://code.chrismorgan.example/chrismorgan/repository-name? https://code.chrismorgan.example/repository-name là đủ rồi mà
Tôi nói nghiêm túc đấy, và nhìn vào https://github.com/go-gitea/gitea/issues/11028 thì rõ ràng có khá nhiều người cũng muốn điều này
Đây cũng là một trong ba lý do lớn nhất khiến tôi không có tài khoản Fediverse: địa chỉ của nó quá kinh khủng
Với địa chỉ kiểu @me@chrismorgan.info thì với một số người có thể nó chỉ hiện ra như “@me”, còn @chrismorgan@chrismorgan.info thì tôi ghét chỉ vì nhìn nó thôi
ATProto đã làm phần này rất tốt. Tên miền là handle tuyệt vời, và nếu cần nhiều người dùng thì subdomain là đủ
Ngay cả với forge dùng chung, dùng subdomain có lẽ cũng có thể tạo cảm giác hợp lý như đơn người dùng. Hãy thử tưởng tượng chris-morgan.github.com thay vì github.com/chris-morgan, cũng có thể khá thú vị
Tính thẩm mỹ là quan trọng
Hướng tới đơn người dùng còn kéo theo hệ quả lớn hơn. Dù có thu nhỏ thứ như Mastodon cho một người dùng thì nó vẫn nặng nề, còn các dự án Fediverse được thiết kế ngay từ đầu cho đơn người dùng lại hợp với mục đích đó hơn nhiều
Tôi muốn tự vận hành server của mình nhưng người dùng cục bộ chỉ có một mình tôi, và không muốn phải thỏa hiệp chỉ vì khả năng có thể tồn tại người dùng khác
Điều này cũng có nghĩa là với một forge, thay vì username chung chung như
git, tôi muốn push bằng usernamechrisnhư SSH thông thườngNếu đã là forge theo nghĩa thông thường thì liên hợp tất nhiên là cần thiết. Nhưng trên “home server” của mỗi người, sẽ tốt nếu chỉ có đúng một người dùng cục bộ
Nếu dùng tên miền mang tên mình thì ở đó chẳng phải cũng có vấn đề tương tự sao?
Tôi thích bài viết của Nesbitt về chủ đề này
Đặc biệt là phần giao tiếp tốt hơn với downstream
Cần có khả năng review code cục bộ trong trình soạn thảo đã chọn
Tôi không muốn bị nhốt trong giao diện web chậm chạp dùng font không đổi được và tô sáng cú pháp tệ hại
Hiện tôi dùng workflow với công cụ tùy biến cho Neovim để xem diff cạnh nhau cho đẹp, và lệnh
git prđể checkout pull requestNhưng chỉ cần muốn thêm chút gì đó như để lại bình luận review thì tôi lại phải phụ thuộc vào CLI của ai đó hoặc công cụ nói chuyện với GitHub API, những thứ rất có thể 5 năm nữa chẳng còn ai duy trì
Nói chính xác hơn, thứ cần thêm không chỉ là công cụ có thể “chạy được” ở máy cục bộ, mà là công cụ ưu tiên cục bộ tích hợp cục bộ với trình soạn thảo và các môi trường khác
Lý do khiến điều này khó trở thành tính năng hạng nhất là công sức cần bỏ ra quá lớn. Một giao diện web duy nhất thì “hoạt động” trên mọi nền tảng và môi trường biên tập vì nó ép người dùng phải dùng nó; còn tích hợp chặt hơn thì nếu có N trình soạn thảo và N môi trường, sẽ cần N tích hợp
CI cũng tương tự. Tôi muốn dễ dàng chạy test trên Linux, FreeBSD, macOS mà không phải push commit lên nhánh rồi chờ 15 phút xem job có được pick lên không
Một thứ kiểu
run-remotely some-command --on freebsd,linux,maclà đủVề cơ bản, đây là một hệ thống CI phi tập trung nhưng ưu tiên cục bộ, đồng thời cũng phải hỗ trợ một hệ thống trung tâm đóng vai trò nguồn chân lý duy nhất để đảm bảo mọi code đều đi qua cùng một hệ thống “được phê duyệt” trước khi merge
Nó vượt xa một lệnh
ssh user@host command ...đơn thuần, vì phải bao gồm sao chép mã nguồn, caching, cài đặt các phụ thuộc cần thiết, v.v. để mỗi lần đều có được cùng một trạng thái đáng tin cậyTuy vậy tôi không cho rằng đây là tính năng của forge. Nó nên được cung cấp như một công cụ job runner có thể dùng mà không cần một forge cụ thể, và bất kỳ forge nào cũng có thể gọi tới
Tôi nghĩ nó nên có phần nào đó kiểu “driver-based”. Có thể chạy cùng một job hoàn toàn cục bộ, hoặc gửi nó sang hệ thống từ xa để khởi chạy. Job đó có thể chạy trong máy ảo, container, hoặc trực tiếp trên máy
Nó cũng nên hỗ trợ hệ thống quản lý phiên bản không phải Git
Cần có khả năng nhập và xuất issue, wiki, v.v. theo định dạng thuận tiện để không bị khóa vào một hệ thống cụ thể
Việc self-host cũng phải dễ dàng
Có lẽ sẽ có một phạm vi con nào đó thực sự quan trọng
Heptapod trong bình luận cùng nhánh dành cho Mercurial, và sourcehut cũng vậy
Fossil có forge riêng của nó, còn allura, phiên bản Apache của SourceForge, cung cấp Subversion
Tôi muốn có một forge cung cấp thứ gì đó na ná Bazel ở lớp CI
Không phải kiểu “có thể chạy Bazel trong CI”, mà là một dạng tự nhiên khuyến khích mọi người viết các bộ test và build tốt, có dependency rõ ràng, để không vô cớ đốt thời gian CI
Liên quan đến đó, tôi cho rằng mô hình “một dự án = một kho mã” đã tạo ra rất nhiều vấn đề
Có thể diễn đạt là hỗ trợ monorepo tốt hơn, nhưng về cơ bản những thứ như CI và issue cần có khả năng được xác định phạm vi ở cấp lớn hơn “thư mục gốc này”
Nhiều dự án bị tách nhỏ kho mã vì lý do forge hay CI, và làm việc trong trạng thái đó thì chẳng vui vẻ gì
Với tư cách reviewer, tôi cũng muốn tách patch nội tuyến
Ý tôi là hãy cho tôi chọn những phần tôi thấy ổn và chỉ phê duyệt những phần đó, để các phần đạt yêu cầu có thể được tích hợp
Tôi vẫn thấy stacked PR là một khái niệm quá nặng
Nếu ai đó nói “tôi muốn sửa 4 file và xem đây là một PR”, thì reviewer nên có thể nói “được, 2 file này ổn”, rồi biến cụm thay đổi đó thành một phần riêng của PR, hoặc thậm chí merge riêng mảnh đó thành một commit khác
Ngay cả stacked PR hiện tại cũng vẫn coi PR là đơn vị nguyên tử. Trong hầu hết hệ thống, tôi thấy PR quá nặng nề
Lý do của họ là “đó là tập con của file, nên không biết có biên dịch được không”
Tôi hoàn toàn không đồng ý với quan điểm đó, nhưng để làm kiểu này trong web view thì quả thực phải khá cẩn thận, nên đọc bình luận này làm tôi nhớ ra điều đó
Tất nhiên, tạm gác sang một bên chuyện như bình luận phía trên nói rằng nếu là chủ kho thì bạn cứ force-push phiên bản mình thích lên nhánh là xong
Cần có cấu hình CI/CD gần như không tốn công
Chỉ cần
make build,make test,make uploadlà đủHãy để phần còn lại trong makefile, rồi từ đó ai muốn thì tiến tới hệ thống build tốt hơn
Tôi muốn đi từ ý tưởng đến artifact đã được publish trong vòng chưa tới 2 phút
Thay vì thế, giống như đa số hệ thống CI/CD hiện nay, chỉ cần dùng các file cấu hình ở vị trí quen thuộc, hoặc đặt ba shell script với tên quen thuộc trong một thư mục quen thuộc là được
Thêm nữa, nếu cần build trên Windows thì có thể làm thành file
.batNó có thể khác nhau theo hệ điều hành, và bạn có thể không muốn nhét nó vào makefile
Điểm hay là mọi job đều chạy trong pty riêng của nó dưới zmx
Bạn có thể attach vào job bị lỗi rồi nhấn mũi tên lên và Enter để chạy lại
Tôi muốn có security advisory với các rào chắn phù hợp để dữ liệu được công bố có chất lượng
Cần có một hệ sinh thái xoay quanh commit để mọi dự án đều có thể công bố dữ liệu có ý nghĩa, đồng thời những dự án muốn thế cũng phải có tích hợp để tự phát hành CVE