[Nix-dev] [***SPAM***] Re: Adoption of C4

[Michael Raskin]

>The minimal idea is: maintainers dont do 'deep' code reviews. They
>just glance over the patch and make sure it qualifies as a correct
>patch, as defined by C4. After travis goes green they hit merge.
>
>If a bug gets in, its not their fault. The community responds quickly
>with a fixing patch.

Let me tell you that NixPkgs has a long history of some complex package
getting left without a maintainer and waiting a few months until someone
even tries to provide updates for it.

>Main points a maintainer is aware of: no public API breakages and it
>compiles. (travis does wonders for point 2).
>
>This rather counter intuitive approach means contributors become more
>careful. It also means more eyeballs are watching and when shit hits
>the fan its all hands on deck.

Some people have expended noticeable amount of time to set up Travis for
NixPkgs. Still, we have «Travis failed — Let me see — Ah, it's 
a transient».

Also, ZeroMQ builds in 3 minutes. In NixPkgs we have a saying — 
LibreOffice depends on everything. This also makes usage of feature
branches for wide collaboration more reasonable. 

«Check that master still builds after the patch» takes multiple days
for NixPkgs.

As for public API — you need to check not only whether you break an
existing public API, but also whether you create a public API that is
destined to be broken too quickly. I think such situations create the
most complicated discussions in NixPkgs.

Also, checking the public API breakage is hard for NixPkgs. GNU TLS 
updates tended to make libsoup build and work with nicely configured
servers, but break with some less recent ones… The shiny C4 story 
doesn't even provide a revert policy… and each clarification of revert
is a significant reduction of frustration for NixPkgs committers.