Gitlab workflow

[Sven Panne]

Am So., 7. Juli 2019 um 17:06 Uhr schrieb Bryan Richter <b at chreekat.net>:

> How does the scaling argument reconcile with the massive scope of the
> Linux kernel, the project for which git was created? I can find some middle
> ground with the more specific points you made in your email, but I have yet
> to understand how the scaling argument holds water when Linux trucks along
> with "4000 developers, 450 different companies, and 200 new developers each
> release"[1]. What makes Linux special in this regard? Is there some second
> inflection point?
>

Well, somehow I saw that example coming... :-D I think the main reason why
things work for Linux is IMHO the amount of highly specialized high-quality
maintainers, i.e. the people who pick the patches into the (parts of) the
releases they maintain, and who do it as their main (sole?) job. In
addition they have a brutal review system plus an army of people
continuously testing *and* they have Linus.

Now look at your usual company: You have average people there (at best),
silly deadlines for silly features, no real maintainers with the power to
reject/revert stuff (regardless of any deadline), your testing is far from
where it should be etc. etc. Then you do everything to keep things as
simple as possible, and having a repository with no merge commits *is* much
easier to handle than one with merges. If you are happy with merge commits,
by all means continue to use them. The "right" way of doing things depends
on so many factors (project size/complexity, number/qualification of
people/maintainers, release strategy/frequency, ...) that there is probably
no silver bullet. The good thing is: Git doesn't prescribe you a special
kind of workflow, it is more of a toolbox to build your own.

I would very much like to turn the question around: I never fully
understood why some people like merge-based workflows so much. OK, you can
see that e.g. commits A, B, and C together implement feature X, but to be
honest: After the feature X landed, probably nobody really cares about the
feature's history anymore, you normally care much more about: Which commit
broke feature Y? Which commit slowed down things? Which commit introduced a
space leak/race condition?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190707/62d6d864/attachment.html>