[Nix-dev] Commit access

[Michael Raskin]

>> 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.