[pacman-dev] Planning the move to the Arch Linux Gitlab instance

[Anatol Pomozov]

Hi

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.

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...