On Fri, Jun 22, 2012 at 01:39:04AM +0400, Michael Raskin wrote: > >> Noticeable part of major feature proposals get neither positive nor > >> negative review and get buried by inaction before the next person who > >> could benefit of the proposed changes appears. > > > >That's bad, but the alternative can't be to just let everybody potentially > >poor > >quality changes just because nobody commented on them. > > Well, given that even controversial changes are usually local, and > when there is discussion it sometimes leads to the decisions strictly > worse than any of the initial options (like in the case with the > parallel builds), and the most annoying problems come from the seemingly > most benign updates, and there is already more work in simply updating > the packages we have than we have resources to do - the alternative you > name seems better than "everything via pull requests".
Heavy nihilism. :) We can try different approaches for a few days. Let's see how it goes, complaints come, etc. For example, I find it cumbersome to put my changes in a pull request; maybe I do it wrong, but to update gdb (after I have my github fork): - I checkout to a new branch, gdbupdate. - I commit my change there. - I push my new branch to my fork - I go to the website, find my branch with the very fast and clean interface of github (ehem) - Click on pull request After some hours, someone accepted my request, then: - I fetch from NixOS/nixpkgs - I pull from its master into my master - I push to my own github fork - I remove my 'gdbupdate' branch: git push ... --delete 've not been wanting to do a new change while the gdb version update was not accepted, but if I wanted to do a new change, should I make it into another branch from master, or from my 'gdbupdate' branch? Or I should start using topgit or things like those, to get all together? Regards, Lluís. _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
