Hi On Sat, May 2, 2020 at 1:29 AM Allan McRae <al...@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...
