[pacman-dev] Planning the move to the Arch Linux Gitlab instance
anatol.pomozov at gmail.com
Mon May 4 06:20:16 UTC 2020
On Sat, May 2, 2020 at 1:29 AM Allan McRae <allan at 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.
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
> 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?
> 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
> Do we leave
> it open until all bugs get closed?
> 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.
> 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
More information about the pacman-dev