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

[Eli Schwartz]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/pacman-dev/attachments/20200504/aa11263a/attachment.sig>