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