[3] ~~Gitlab/Github integration~~

[Arsen Arsenović]

Andrew Pinski <pinskia@gmail.com> writes:

> On Sat, Sep 14, 2024 at 2:47 AM Florian Weimer <fweimer@redhat.com> wrote:
>>
>> Skip this time (see 2023 discussion).
>>
>> * Use of free software vs enabling modification of free software
>> * Time spent on status during patch review call
>> * Do we provide feedback to new contributors?
>
>
> A few notes on gitlab vs github vs gerrit from my side.
> github tends to love everything together (issues and pull requests)
> and is very much non-free and even owned by Microsoft who has in the
> past been very anti-free software.
> "Everyone" knows github because they cornered the market rather than
> being useful.

I agree with this part.

> pull requests are harder to review than patch sets. pull requests have
> the tendency to do multiple patches together and there is no way to do
> dependent pull requests in  github (see old request here:
> https://github.com/isaacs/github/issues/959 ).  Looks like gitlab has
> support though. But it seems harder than just submitting a patch set:
> https://docs.gitlab.com/ee/user/project/merge_requests/dependencies.html
> .
>
> If we want to keep around patch sets instead of pull requests and do
> linear history (which I 100% hope we keep since it is easier to bisect
> and even understand history), then pull requests need to be squashed
> and not useful for reviewing patch sets.

Not really - you could either not merge using the web UI, using a tool
like 'pram' (see Gentoo for an example of this) instead, or do web-merge
with rebase (loses commit signing), which will take the patchset and
rebase it before fast-forwarding to the rebased patch.

Still more fiddly to submit though.

> This is where something like gerrit comes into play since it is more
> about handling linear history rather than pulls. It has support for
> dependent patch sets, patch sets themselves, each patch can be
> reviewed separately rather than as a single pull.
>
> There might be other gerrit like systems out there but I don't know of
> any that are as popular.
>
> Thanks,
> Andrew Pinski
>
>
>
>>
>> This is a very controversial topic. In 2023, Joseph made an observation
>> that I think was spot-on: none of the alternatives to the email-based
>> patch workflow are compelling enough to tempt us to switch.
>>
>> Old notes:
>>
>> Gitlab and especially Github is what people know, so they could be a
>> tool to interest people in glibc development and get there first local
>> build going.
>>
>> Patchwork (which we currently use during the Monday patch review call)
>> is hidden from most contributors, patch status has to be updated
>> manually. Status updates in Patchwork need to be conveyed manually to
>> the patch submitter.
>>
>> It’s not really clear if we provide actionable, timely feedback to
>> contributors. Saying No is hard, but closing a merge/pull request
>> without merging it sends this clear message.
>>
>> (2024 note) skip, refer to Joseph’s comments (no totally compelling
>> replacement).  We also have the Monday patch review meeting.
>>

-- 
Arsen Arsenović
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20240915/9192fd0b/attachment.sig>