@jwildeboer well... it is **a** workflow... which has...

Jan Wildeboer 😷:krulorange:'s posts Post Back to profile

@jwildeboer well... it is **a** workflow... which has nothing in common to mailing list based contribution.

GitHub/GitLab's PR workflow is an absolute disaster/nightmare for per-commit/patch review. Gerrit does that a bit better with patchsets but it gets difficult to read pretty quickly, even with topics.

GitLab/GitHub is just NOT necessarily compatible with some project's workflow.

I actually wrote a multiple pages long email on why no GH/GL for Yocto a while back, maybe I should put it in an article so it's easier to explain everything instead of being limited to a few 100s of characters at once :)

Like 3 October at 12:57 | Wall-to-wall | Open on piaille.fr

4 comments

Jan Wildeboer 😷:krulorange:

@0leil Please do! I will also start a blogpost on how Discord etc mess up communication in a project (IMHO) by mixing synchronous and asynchronous communication together in a way that isn't helpful but, again IMHO, damaging to the flow.

3 October at 13:00 | Open on social.wildeboer.net

Anthk

@jwildeboer @0leil It sucks, period. A mail list/usenet gives you all anytime.
And IRC will work even with a 386 in a hurry.

3 October at 13:19 | Open on paquita.masto.host

Jonathan Frederickson

@0leil @jwildeboer Per-commit review is a point that I hadn't considered. With GitHub's PR UI only making the end result of all commits together apparent, I could see someone introducing a security vulnerability in a commit, fixing it in another, and then tricking a packager into publishing the version with the vuln...

3 October at 15:46 | Open on jawns.club

ManicDee

@jfred @0leil @jwildeboer per-commit doesn’t make sense when you are just going to deliver all those commits in one PR, same effect as squashing commits when accepting the PR.

Main issue I see is trying to do too much in one PR.

3 October at 22:47 | Open on mastodon.social