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

Georges Dubus georges.dubus at gmail.com
Mon Jan 19 22:26:00 CET 2015

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.

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.

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.

I fell that any proposal would have to take those points into account to
fit NixOS. Sadly, I do not have proposal, except maybe to find a rich
benefactor and throw a lot of money at hydra.

Georges Dubus

2015-01-19 22:00 GMT+01:00 Matthias Beyer <mail at beyermatthias.de>:

> On 19-01-2015 10:15:16, stewart mackenzie wrote:
> > I request that we come up with a detailed and carefully thought out
> > contribution guideline which evolves and grows.
> I guess that would be the best idea, but I'm just a "Users voice" if
> you want to name it this way.
> So, be careful, Users voice ahead!
> Generally, I think it would be best to prevent commit access as far as
> possible. Having more people to be able to commit to master results in
> many different opinions committing to master, which therefor results
> in discussions, eventually flamewars and everything.
> Keeping commit access for only a few people does not mean that things
> get slower, no way! For example there is the issue with trivial
> patches discussed in this thread. Trivial patches are generally
> patches which should go into master as fast as possible, I fully agree
> with that. New packages may be the same, you want them to be in master
> as fast as possible. But at some point you have to balance between
> speed of development and maintaining efforts. It has absolutely _no_
> benefit if a trivial patch gets pushed onto master whereas one or two
> other revert them shortly afterwards because they do not agree. This
> is software development, not pingpong!
> What you maybe want, at least from my point of view, is staging
> branches. Some kind of a hierarchy of maintainers, as you have in the
> linux kernel. I fully understand that the linux kernel is a _way_ more
> complex system as nixos/nixpkgs, no discussion here. But if you'd
> split up responsibilities, you may end up with
>     * A fast _and_ secure development model, as people don't revert
>       back and forth.
>     * Fewer "wars" because people disagree on things
>     * Less maintaining efforts, because the effort is basically split
>       up in several small "problems", which are faster to solve.
> What I want to say is, basically, you want a well-defined and
> structured way of how to do things. The costs may be that your
> development gets a bit slower but you have the benefit that if things
> break you don't start yelling at eachother (I assume you don't do
> this, but lets put it this way) because certain people disagree on
> certain topics.
> My proposal: Responsibilities should be defined.
> For me, as simple package contributor, I want to have _one_
> place/person/branch/ML/whatever where I can ask questions and
> contribute packages to, leaving the official NixOS github repo
> completely alone! I, personally, would even be fine with sending
> git-patches per mail to a ML where it gets reviewed (, maybe build by
> a daemon, tried to be merged into a nixpkgs/pkgs-branch) and
> afterwards committed onto a package-branch of a maintainer, which
> requests a merge into the master branch every now and then.
> This workflow would have several benefits:
>     * Less "merge noise" in the repo
>     * Less "PR" noise on github
>     * One (or two, or three,... but ideally just one) maintainers have
>       the responsibility that the new-packages branch actually _builds_
>       and should never commit broken packages onto it. If they fail with
>       this, they are bad. Period.
>     * If you do this on a dedicated ML you have less noise here and
>       also a topic-ML, where only packages are reviewed. This also
>       enables new contributors to collaborate with other
>       package-contributors which is an advantage as they actually can
>       help eachother.
>     * If, on a merge, people disagree, patches can simply be reverted
>       _on that topic branch_, resulting in absolutely _no_ merge
>       noise, PR noise or anything.
> ---
> Please note, I'm relatively new to NixOS and the community and if
> _anything_ of the said pisses you of in _any_ way: It wasn't meant to
> do so and I'd really like to hear your arguments! If anything I said
> makes you think that it's written in an angry way or something, it is
> not, it's certainly just my bad english. I just want to state my point
> and my oppinions here.
> --
> Mit freundlichen Grüßen,
> Kind regards,
> Matthias Beyer
> Proudly sent with mutt.
> Happily signed with gnupg.
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20150119/574f7f00/attachment.html 

More information about the nix-dev mailing list