Re: [Nix-dev] Again: Why don't these people have commit access
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 m...@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
Re: [Nix-dev] Again: Why don't these people have commit access
Marc I think it's the general case of more complex PRs. PR that change too much or add too much tend to be delayed. Not only because they are harder to test, but also harder to agree on by more peopl Well - I did take care - I added the new cups version as opt-in. It was your choice. You were free to keep using the old one. I think history is history.. we should talk about the future which also might affect guix (http://www.gnu.org/software/guix/) In the Vim community people leave over and over again because patches don't get accepted or are not taken care of. Just about 2 days ago there was another case. I think that being able to use nixos as desktop system (which implies being able to print) should be a high priority. We also have a new situation compared to back in the old SVN days: _We have releases_ Thus breaking stuff is still bad, but maybe less bad than before. The problem is: We all need stable systems - thus if everybody uses the stable systems nobody is going to use the less stable - thus less testing will happen. But let's talk about a specific case: My patches to apache httpd module: https://github.com/MarcWeber/nixpkgs/commit/7cdeb3f63ee1e26b6113754995284c56257ef162 The apache one breaks the API because I don't want to mess with port stuff (to not mess with .htaccess) so I just created my own loopback device .. Figuring out how to patch this in a backward compatible way was something I could not afford. My current situation is that I update my system only once every couple of weeks because I cannot afford recompiling everything over and over again. Just to say, it's not lack of trust, or being negative. It's lack of time (or platform) for proper testing and lack of time for proper understanding (linux is becoming too giant) the consequences of a change. Well - NSA cases and the one fosdem video (what would I do If I had one million $ and if it was my task to compromise the world ..) was fun to watch: http://video.fosdem.org/2014/Janson/Sunday//NSA_operation_ORCHESTRA_Annual_Status_Report.webm Thus to truly improve you also have to start measuring who reviewed commits to maximize value by spent time - and that not only for nixpkgs but also for projects like openssh. There is no way to ensure that an update will not cause a random failure on hardware X which will happen only once a month. One huge benefit from having commit access would be that experimental or complicated stuff could be submitted as topic cranch to increase visibility and that other people can join such effort and help taking it to a level where it can be merged. I love topic branches because they use two files: .topmsg = The commit message which would be created when all commits got collapsed. The nice thing is that each branch documents its purpose on its own. .topdeps A list of other branches it depends on Then there is a tg update command to merge with all dependencies and a tg export command to collapse in order to yield a nice commit which can be reviewed more easily. The wiki contains a longer introduction. I don't say topgit must be used. But I highly recommend having such topic specific file documenting the purpose of a branch That's another story: do we want many official experimental topic branches? Making experimental branches visible to others would improve collaboration a lot. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Again: Why don't these people have commit access
(Slight topic digression: parallel make.) On 01/19/2015 06:59 AM, Michael Raskin wrote: This is also the reason why we have no idea which of the packages are safe to build in parallel except for the few packages where someone explicitly tried. Perhaps I don't understand you, but hydra.nixos.org seems quite successful in finding underspecified makefile dependencies. Vladimir smime.p7s Description: S/MIME Cryptographic Signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Again: Why don't these people have commit access
On 01/19/2015 07:17 PM, Michael Raskin wrote: To find out if a makefile is parallel-safe, we need to try it with parallel building enabled. This can only be done package-per-package, [...] I see. What I said is only true for packages with enableParallelBuilding = true; Vladimir smime.p7s Description: S/MIME Cryptographic Signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Again: Why don't these people have commit access
On 20-01-2015 00:10:29, Michael Raskin wrote: * 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. You ask for a strong committment for keeping an eye on a huge stream of changes. How many maintainers a year do you plan to expend this way? Well, that's my point of having not only one person doing it. Anyways, it would be best if only one person would maintain the new-packages-branch, as this simplifies a lot of stuff. Anyways, I don't say that only one person should review the patches, of course! And of course it is committment, but so is everything in developing a distro or software, I guess! On the huge stream of changes part: Is it actually that much already? How many packages are there per week, for example? I don't think it is _that_ much, ... For example, there are currently 25 PRs on github with the tag new-package, only 10 of them from the last 10 days! It is really not that much! -- Mit freundlichen Grüßen, Kind regards, Matthias Beyer Proudly sent with mutt. Happily signed with gnupg. pgpD7BLgf2zzr.pgp Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Again: Why don't these people have commit access
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 m...@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
Re: [Nix-dev] Again: Why don't these people have commit access
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. pgpci1WcDSOa2.pgp Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Again: Why don't these people have commit access
On 20-01-2015 00:34:22, Michael Raskin wrote: On the huge stream of changes part: Is it actually that much already? How many packages are there per week, for example? I don't think it is _that_ much, ... For example, there are currently 25 PRs on github with the tag new-package, only 10 of them from the last 10 days! It is really not that much! I am not sure all PRs are tagged properly... I'm sure there are PRs around which are not tagged properly, of course. That was just to get a rough idea of the number! Also, where do version bumps go? Good question. -- Mit freundlichen Grüßen, Kind regards, Matthias Beyer Proudly sent with mutt. Happily signed with gnupg. pgp0M8jKf13DL.pgp Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Again: Why don't these people have commit access
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. pgp3UnR1LBpF0.pgp Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Again: Why don't these people have commit access
I request that we come up with a detailed and carefully thought out contribution guideline which evolves and grows. It should keep pychopaths under control, expand bottlenecks and make this development process fun! I've suggested Pieter Hintjens C4 and ensuing private discussions made it clear the approach is _not_ compatible with NixOS. Therefore with the C4 in hand might we start editing and adapting it to our needs? ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Again: Why don't these people have commit access
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 19 Jan 2015 00:33:04 + Marc Weber marco-owe...@gmx.de wrote: - I have patches pending for apache http and nginx making them more configurable (eg allowing to set the IP to listen to) Do you mean listen address per virtual host ? That would be really great to have. At the moment it is not possible to use multiple HTTPS virtual hosts on the same machine due to the lack of a configurable IP address per virtual host. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iJwEAQECAAYFAlS8sCEACgkQDog4ovJRA8RpNAQAqOm8ZSgexR5KnykVAAE9UU64 DXuumr9FJVV3ImKV6RAWZv5W1l43oChL2yhBDOCgLia/hZo9SD7GNzK+TVKIV/A0 xyZbbVP+jhNjkJFUYtq5jn5YxNy6FI5rvp+xxjNZ2Y4TeAx/pDroYZAG+9+9sL4S HqzOxu/4xBY0/524t0Q= =W0+J -END PGP SIGNATURE- ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Again: Why don't these people have commit access
I can only speak for myself: In the past the community or some members didn't accept what I did for various reasons. That's why I did no longer run for 'commit' access since then. A summary with some cases (some time has passed, maybe my memory is no longer that accurate - but it should give an idea): - patches about parallel building got stuck = result: 3 people (Lluís Batlle, me , Peter) tried different implementations. The first patch was not accepted for no reply is no ok reason - I didn't get a ok due to minor refactoring of make arguments in builder and because some people feared about purity (it would have been opt-in) I messed up hydra that time (due to some -n -j being interpreted as run as much as possible) It was pretty depressing for me because I had need for -j 4 and not getting it into nixpkgs made it impossible for me to use hydra. - patches about cupsd got stuck (due to using versionedDerivation) = fixed printing for me - was later asked on the mailinglist for) - I did mess up python once and did not have time within 5 days or so to fix it - those had to be reverted by Eelco Dolstra - Work on php-fpm was done twice, by me and by somebody else. My version of php-fpm is more complicated but also very complete because it determines how many php-fpm daemons to start on its own. - I eventually had pushed the zsh/bash patches (which I guess are partially obsolete now) - they allow users to opt-out and allow modules/the admin to define bash/zsh snippets to be added to a global bashrc/zshrc which gets sourced by ~/.bashrc so that users can opt-out from everything or pieces. - I would have fixed eigen(2) in krita of calligra much faster = Thus because I have not had commit access this had to be debugged twice. - I have patches pending for apache http and nginx making them more configurable (eg allowing to set the IP to listen to) To sum up: I tend try to apply the 20/80 rule: 20 percent of effort should yield 80% of the desired result - which seems not always to be good enough. Thus in the past I caused both: goodness and badness - thus its fine for me that my commits get reviewed. Thus if PR's don't get accepted I do no longer take it personally - changes end up in my topic branches instead. I treat Nixos to be a very good option to get some jobs done - still seeing much room for improvements. Eg there are 3 implementations: nixpkgs/a js one and guix. Thus moving towards a global package database more distros could derive package descriptions from is much more important to me than caring too much about policies - because I see Nixos to be a tool only to get a job done. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Again: Why don't these people have commit access
Marc I think it's the general case of more complex PRs. PR that change too much or add too much tend to be delayed. Not only because they are harder to test, but also harder to agree on by more people. Easy PR are in fact faster to be pushed. Increasing the number of committers is certainly good. Of couse, as a committer, it's not that you have to always push your own complex stuff, instead create a PR. You for example you could certainly push commits that in most cases don't affect much people or that you are ready to revert, ecc. ecc. I was never asked for following any rule, except not triggering mass rebuilds, when got commit access. I tend at committing simple stuff that don't break, otherwise still create a PR. Your unfortunate case is that most of your PR are complex or controversial :P offlinehacker has the same problem, he has different needs and obviously want to push those needs. And many others. Also some PR are basically very hard to test for many people. For example testing new kernel options. Or because committers don't have knowledge on every field, and thus resilient to push. Just to say, it's not lack of trust, or being negative. It's lack of time (or platform) for proper testing and lack of time for proper understanding (linux is becoming too giant) the consequences of a change. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Again: Why don't these people have commit access
Pascal Wittmann pascalwittm...@gmx.net writes: On 01/18/2015 06:19 PM, Nathan Bijnens wrote: While I don't mind that we expand the number of people with commit access, I firmly oppose doing changes directly on master, any change should first be a PR. If there're more people who can close a PR, those PRs will be open for a shorter amount of time. What is the advantage? IMO this would create an enormous overhead. E.g. I just updated abiword from 3.0.0 to 3.0.1 and only changed the version number and hash. Is this worth a pull request? I don't want to merge those pull requests, they only cover the discussion-worthy pull requests. I totally agree here: Simple version-updates, fixes, (simple) new packages, etc. should go into master/staging without a PR. We can still create pull requests for bigger changes and/or controversial ideas. signature.asc Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Again: Why don't these people have commit access
On 01/18/2015 06:19 PM, Nathan Bijnens wrote: While I don't mind that we expand the number of people with commit access, I firmly oppose doing changes directly on master, any change should first be a PR. If there're more people who can close a PR, those PRs will be open for a shorter amount of time. What is the advantage? IMO this would create an enormous overhead. E.g. I just updated abiword from 3.0.0 to 3.0.1 and only changed the version number and hash. Is this worth a pull request? I don't want to merge those pull requests, they only cover the discussion-worthy pull requests. signature.asc Description: OpenPGP digital signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Again: Why don't these people have commit access
Michael Raskin 7c6f4...@mail.ru writes: While I don't mind that we expand the number of people with commit access, I firmly oppose doing changes directly on master, any change should first be a PR. If there're more people who can close a PR, those PRs will be open for a shorter amount of time. Many people come and say that. The sad truth is that we lack the resources to do development like that. Whatever the benefits of this approach, we cannot afford the costs. The low observed rate of PR merges means that we need people who do many correct small updates to perform them directly on master for the project to be able to actually accomplish something except the trivial updates. I entirely agree, Michael. As one of the people who commits directly to master, I have to say that if every small change/fix I wanted to make had to go through a PR, I'd contribute much less, simply due to lack of energy. John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Again: Why don't these people have commit access
On Sun, Jan 18, 2015 at 07:53:35PM +0100, Moritz Ulrich wrote: Pascal Wittmann pascalwittm...@gmx.net writes: On 01/18/2015 06:19 PM, Nathan Bijnens wrote: While I don't mind that we expand the number of people with commit access, I firmly oppose doing changes directly on master, any change should first be a PR. If there're more people who can close a PR, those PRs will be open for a shorter amount of time. What is the advantage? IMO this would create an enormous overhead. E.g. I just updated abiword from 3.0.0 to 3.0.1 and only changed the version number and hash. Is this worth a pull request? I don't want to merge those pull requests, they only cover the discussion-worthy pull requests. I totally agree here: Simple version-updates, fixes, (simple) new packages, etc. should go into master/staging without a PR. We can still create pull requests for bigger changes and/or controversial ideas. Remember that we use a comfortable VCS, and it is quite easy to take back things if the changes seem not to work well. And they can be reapplied again later if they were doing the right thing, etc. As for me, let the listed contributors commit to master! ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
