Hi On Sat, May 2, 2020 at 1:29 AM Allan McRae <allan@archlinux.org> wrote:
Hi all,
Arch Linux is setting up its own Gitlab instance. I have been playing around with it for the day and I think pacman should transition there.
Yay!!! Finally. Thank you Sven-Hendrik and others for your work!
Note: the current pacman repo on the Arch Gitlab is a playground I have been using. It will be deleted.
There are some features that are of interest: - CI on merge requests, which will catch build issues automatically. - Review where I can easily see what changed on resubmission - integrated bug tracker, patchwork, ... meaning I spend less time updating things on multiple sites.
I've been using review tools like Gerrit and Gitlab at my dayjob for almost 10 years now. And personally I find this way of reviewing patches more productive than using maillist. Gitlab-like UI provides reviewing context, adds syntax colorizing, allows to track what has been reviewed and what has not. Plus Gitlab allows to automate some boring tasks.
We can also do things like provide regular developers a namespace. e.g. I would own allan/* branches, and could prepare work and request merges from branches there.
That would be great. I know Gerrit tool has $user namespaces where people can keep large refactorings before it is ready for a review. We should also invest some efforts into setting up Gitlab automation using bots. Bots could run tests, check spelling, run lint, update "pacman-git" AUR package etc, etc....
So how would we proceed?
Bugs: Do we pick a date where we disable new bug submissions on the current tracker and point towards gitlab? Are old bug transferred after some ruthless trimming - I don't think this can be automated...
Do we want to try to move bugs to Gitlab or we start Gitlab bug database from scratch? I personally fine with either case but if we choose the latter option then bugs.archlinux.org should stay available read-only as an archive of the discussions. Sven-Hendrik what is the current state of git/flyspray -> gitlab migration toolset?
Do we leave it open until all bugs get closed?
Patchwork: The got "cleared" somewhat recently, when an update occurred. At bit of effort could followup al the changes needed that never were done and clear this out.
Mailing list: New patches would no longer appear here. I don't know how much we can get gitlab to report to the mailing list, or if we even want to. The mailing list would still serve as a good place to discuss feature implementation in a more public way.
Date: What is a good time for all this to happen? Once Anatol's parallel downloads patches are fully committed, I'd like to make a 6.0.0beta1 release to get some good coverage on these changes. Could we move at the same time?
I personally would love to try Gitlab for my "parallel-download" patchset review. But I guess Gitlab instance is not ready for it yet...