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

[Matthias Beyer]

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.
-------------- 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/e7ead0f9/attachment.bin