[pacman-dev] Planning the move to the Arch Linux Gitlab instance
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. 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. 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. 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 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? Let me have opinions. Cheers, Allan
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...
On 5/4/20 2:20 AM, Anatol Pomozov wrote:
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.
patchwork also provides both syntax coloring and review tracking. Review context is provided for free. It's really not about these features. Gitlab is an integrated software forge which provides this all together, that's all. Better than some in some ways, worse than some in other ways. But if you value *integration*, then it's a win over having multiple locations to do everything. Is there a reason you sound like an infomercial?
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.
I don't think anyone suggested moving to gerrit... developer namespaces are not a new concept anyway, you can do them with gitolite too. Gitlab may provide them as part of the package deal, sure, but we hardly need gerrit for this...
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....
How are bots different from CI, which already runs tests? I'm not sure what you mean by "bots". (Note that Allan has submitted a patch to add .gitlab-ci.yml, before this thread even started, so as far as I can tell we don't need to invest any more efforts as it has already been done. If there are concerns about it, please address them there.) What "spelling checks" are you proposing, I don't think I've seen that before, plus spelling and grammar checkers are not exactly known for their sterling accuracy. Are there known problems with spelling in pacman? Prose is pretty unambiguously right or wrong, so if there are problems it should be a one-time fix. No one's updating the pacman-git PKGBUILD, the AUR guidelines forbid frivolous pkgver bumps on every upstream commit. When changes to e.g the build() function are needed, I'll be happy to update the PKGBUILD (since I am the current AUR maintainer), but it will be done by hand, and won't be because of gitlab... I already publish and sign binary packages in my custom repo for public use, and it's my belief that this stage should be manual anyway (I'm not giving my PGP signing key to a gitlab runner to use whenever it wants).
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?
I was under the impression previous flyspray work had been focused on bugzilla, not gitlab. Anyway, as far as I can tell Sven hasn't been CC'ed, nor is subscribed to this list, so I'm not sure who you're asking here.
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...
Well, if it's not ready it's not ready... so let's just continue the in-progress review on the mailing list. It's not like there is an urgent need to see how it works for the sake of learning how it works. We know how it works, most of us have undoubtedly used gitlab/github before. Again, this sounds like an advertisement about how you like gitlab, rather than some sort of mission plan for how to use it. -- Eli Schwartz Bug Wrangler and Trusted User
On Sun May 3, 2020 at 7:20 PM EDT, Anatol Pomozov wrote:
Hi
On Sat, May 2, 2020 at 1:29 AM Allan McRae <allan@archlinux.org> wrote:
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.
Perhaps we should have a read-only archive (redirects to the Wayback Machine?) regardless. We have all those references in our package commits and elsewhere (eg. a PR I made just today to an outside project). -- Best, Daniel <https://danielcapella.com>
On 5/2/20 4:29 AM, Allan McRae 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.
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.
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.
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 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.
I know that you're supposed to be able to email patches to a gitlab address and have it generate a merge request. Not sure how notifications the other way work, if at all. I'd quite like to have, at a minimum, a post-receive notification to the mailing list like we currently have... If we don't allow absolutely anyone to create an account on our gitlab instance, then they cannot report bugs, or submit patches (even by email, it's a private email address tied to your account). IIRC devops were not eager to enable public account creation for various reasons.
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?
Let me have opinions. -- Eli Schwartz Bug Wrangler and Trusted User
On 5/5/20 12:55 pm, Eli Schwartz wrote:
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. I know that you're supposed to be able to email patches to a gitlab address and have it generate a merge request. Not sure how notifications the other way work, if at all. I'd quite like to have, at a minimum, a post-receive notification to the mailing list like we currently have...
If we don't allow absolutely anyone to create an account on our gitlab instance, then they cannot report bugs, or submit patches (even by email, it's a private email address tied to your account). IIRC devops were not eager to enable public account creation for various reasons.
On the Arch Linux DevOps channel, I was told that at least for now accounts would be restricted, so no merge requests from those apart from the main contributors. We don't want bug reports to be created without accounts, so that would stop us using this as a bug tracker. This means we would need keep mailing lists for patch submissions (and thus patchwork) and a separate bug tracker. We would have to not use the gitlab instance bug tracker at all, or else we would end with double-ups. Given the restrictions of this set-up, I don't think we should move there for pacman development. I will set up gitlab to pull from our current git so we get CI, but that will be all for now. Allan
participants (4)
-
Allan McRae
-
Anatol Pomozov
-
Daniel M. Capella
-
Eli Schwartz