>> 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.
Last time I breaked a thing (and it was recently), it was my commit and I actually used the resulting binary for some time. Didn't notice the open dialog was broken. So the question is about price-vs-quality, testing doesn't always give as much additional information as one would want… >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 Discussed before, and it got declined. >> 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. I rank reasonableness of notions used in UI as monotone > mercurial > SVN > git I am currently undecided about fossil, although it is definitely in the left half of the chain. git commands are built around gotchas, so I will not even try to get a better frontend, I will just script whatever workflow is considered acceptable and use the same two scripts to minimize errors. >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. For single-commit-branches yes, but then you need to do extra work and for 3–6 commits there is some logic in them being in a single PR. Usually. Not always, though. _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
