[Nix-dev] Commit access

[Herwig Hochleitner]

2016-03-01 0:17 GMT+01:00 Michael Raskin <7c6f434c at mail.ru>:

>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160301/7f094c05/attachment.html