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