[Numpy-discussion] Homu

[Nathaniel Smith]

Hi all,

As an experiment, I just enabled @homu on the main numpy repository.
Basically what this means is that there's a bot named @homu, and if
someone with appropriate permissions posts a comment on a pull request
that says:

@homu r+

then homu will (a) doublecheck that the pull request still passes
tests when merged into current master, and (b) if it does, then go
ahead and hit the green merge button for you. ("r+" is mozilla-ese for
"I approve this patch"; @homu comes out of the rust/mozilla
community.)

So you can still hit the big green button if you want, no change
there, but this provides a second option with a few advantages:

- Normally, a green light from Travis just means that the PR passed
the tests when it was submitted. If master has changed since then,
things might have become broken, but you'll never know until after you
merge it and master turns red.

More minor advantages:

- You can approve a PR before Travis has even finished running, and it
will automatically be merged iff the tests pass.

- In theory, it should be possible to put someone on the @homu
permissions list without adding them to github proper, which would
mean that they have the ability to push to the repository via
PRs-that-pass-tests-and-trigger-notifications, but can't do a direct
commit directly into master that doesn't create any notifications. Not
sure if this is really useful, but hey.

- You don't have to merge-and-then-comment-saying thanks, you can just
post a single comment, saving two entire mouse clicks. Efficiency!

Anyway, seemed worth taking for a spin and seeing whether we liked it;
we can always turn it off again if not. I think that everyone who has
commit access to numpy/numpy is also listed on @homu's access list --
if I missed anyone just let me know.

Links:
http://homu.io/
https://www.reddit.com/r/rust/comments/39sogp/homu_a_gatekeeper_for_your_commits/
http://graydon.livejournal.com/186550.html
http://homu.io/q/numpy/numpy

-n

[Pauli Virtanen]

15.06.2015, 12:00, Nathaniel Smith kirjoitti:
[clip]

Post by Nathaniel Smith
http://homu.io/

One thing to consider is the disadvantage from security POV: this gives
full write access to the Numpy repository to that someone who is running
the bot. I don't see information on who this person (or these persons)
is and how access to the bot and the bot account is controlled.
(Travis-CI doesn't have that AFAIK, it can only change the
passed/not-passed icons.)

Pauli

[Nathaniel Smith]

Post by Pauli Virtanen
[clip]

Post by Nathaniel Smith
http://homu.io/

One thing to consider is the disadvantage from security POV: this gives
full write access to the Numpy repository to that someone who is running
the bot. I don't see information on who this person (or these persons)
is and how access to the bot and the bot account is controlled.
(Travis-CI doesn't have that AFAIK, it can only change the
passed/not-passed icons.)

That's a fair point.

The person running the bot is Barosl Lee (@barosl), who is also the author
of the homu bot (https://github.com/barosl/homu) that the homu.io hosted
service is based on. The Mozilla rust and servo teams are using this code
to manage all their merges, e.g.:

http://buildbot.rust-lang.org/homu/queue/rust

though they are running a self hosted version, not using homu.io.

If we're uncomfortable with the hosted service then hosting it ourselves
wouldn't be hard -- I've actually had "set up a homu instance" as a todo
item for most of a year now (check out Graydon's last comment on the lj
past I linked to upthread, and who he's replying to ;-)). I literally sat
down to get this done last night, got half way through, and then discovered
that @barosl had finally announced their hosted service 18 hours earlier,
so I figured I'd be lazy and just use that instead :-).

Personally I'm not worried about the security issues -- I think the chances
that @barosl is malicious are basically zero, and while every account that
gets access to a repository increases the risk that someone might steal
their credentials and do something naughty with them, the additional risk
seems minimal to me. (Right now there are 16 accounts that have full admin
access to numpy/numpy; @homu is not one of them.)

But if people prefer I'm happy to self-host too.

-n