[Nix-dev] Again: Why don't these people have commit access

[Matthias Beyer]

On 19-01-2015 22:26:00, Georges Dubus wrote:
>    I'm under the impression that none of the proposal inspired by outside
>    project seem to fit NixOS, because NixOS is a very different project : it
>    is a huge and complex linux distro.
> 
>    The first consequence is that it is impossible to have expert on each part
>    on NixOS, because each tiny part requires a specific expertise. To work on
>    python packaging, you have to be a python developer, to work on kde
>    packaging, you have to be involved in the kde community, and to work on
>    libreoffice packaging you have to be knowledgeable on how libreoffice is
>    built (and very patient). I reckon you'll find much people who are
>    confident enough to review a change on a specific part on NixOS than you'd
>    find in another project.

That's indeed a problem I've not thought about yet. I see that NixOS
is a complex distro and I see that we are short in man power, so I
guess my proposal does not fit that well.

> 
>    Secondly, the scope of the project is so huge that checking nothing is
>    broken takes forever. I most projects, you expect contributors to run the
>    tests and make sure nothing breaks, but in NixOS, that's much harder. We
>    make travis timeout, and we do not have enough resources to build a tight
>    CI that tests every pull request before merging it.
> 

My point on this part was not that nothing breaks, but that no new
packages break. Or at least no trivial new packages. For example, I
just packaged "ctodo", which is almost dependency-less. These kind of
stuff really should not break and I guess it is fairly secure to (kind
of) "out source" that from github, as it generates noise in the repo.

>    Finally, even the definition of "broken" is more blurry than in other
>    projets. We usually have a few hundreds failing evaluation in hydra, and
>    the number is quite stable (much fewer than we used to have before the ZHF
>    project, though). Those failures might be linked to unexpected side
>    effects of commits, changes in outside world (a tarball has moved) or any
>    kind of transient failure. It is not possible, as of now, to declare that
>    nothing must break.
> 

Again, this was not the point. The point was that nothing _new_
breaks. Beeing imperfect is not desired (of course it would be ideal),
but getting better is desired. That's a small but important
difference, I think.

-- 
Mit freundlichen Grüßen,
Kind regards,
Matthias Beyer

Proudly sent with mutt.
Happily signed with gnupg.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20150119/3091c011/attachment.bin