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

[M. P. Ashton]

On Mon, Jan 19, 2015, at 04:26 PM, 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.

This is a good point. How has the Debian project handled this situation?
Perhaps there are some good lessons to be learned from the ways they
have organised themselves.

I believe things have been a little tense over there lately, but they
have certainly been successful over the years.

--Michael Ashton

> 
> 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
> >
> >
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev