2016-03-01 0:17 GMT+01:00 Michael Raskin <[email protected]>: > > I do read the patch before; and in many cases I do know what the fallout > will be. >
Sorry, I have to call you on that. Everybody programmer thinks that they can tell what code does (and they often can), but bugs, you know. 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). > Trusting that PR authors tell the truth is fine, I think. In my "multiple upstream branches" model, patches could also go upstream, if the PR author said the requirements were fulfilled. Even if I find it reasonable to test locally, for larger rebuilds, maintainers could be allowed to create hydra builds > 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. > Funny. For me, whenever I have to use github, I'm like "ugh, why can't i use magit (the git frontend I use) to interact with a PR" or "why can't I just apply a PR to my branch". Using the `hub` command is also not much fun. So, as a maintainer I might also end up using the merge button for "obvious" changes, like point updates. But just out of comfort, I'd always push reviewed changes by git. I do realize that this would often mean manually closing PRs, but .. c'est la vie. As to merge vs rebase, I'd rather not get deeply into that debate, however I will note that for single-commit branches the _only_ information a rebase destroys is the original base of the commit, so .. your judgement if that's valuable information to nix-master.
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
