>What does concern me slightly, is the number of merge commits, that I see >in master. Those are usually created by just pressing the merge button. >When actually reviewing stuff, people tend to locally rebase/apply, test to >various stages, and then push. In github, this is visible by "commited >with" commits. >So if there is a problem with "loose cannons" (maybe maintainers can speak >to that), this could be solved by restricting access to master, or by >creating multiple upstream branches for various stages of review like >"looks good, press merge", "merged locally, nixpkgs evaluates, >configurePhase doesn't crash", "built and tested in vm with package >*installed*", "tested referrers" and require maintainers to only push to >those branches when conditions are met.
I usually use GitHub's merge button. I do read the patch before; and in many cases I do know what the fallout will be. Yes, I do trust the submitters not to say explicit intentional lies about whether the package builds and whether some reverse-dependency works after a change (I have to ask sometimes). Even if I find it reasonable to test locally, I will _not_ push from my repo if I haven't done any changes. Why would I bother messing with Git when Github has this button? The button is safer and rebases destroy information. _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
