METADATA push access limited to Julia committers

[Stefan Karpinski]

There's been an increasing amount of chaos on the METADATA repository due to the large number of people who have commit access to it. Because of this, I've restricted push access to people who have commit access to julia itself. Going forward, there will need to be broader changes to how we deal with registering and tagging new packages and versions, but for now this should keep things a little saner. If you want to register a new package or tag a new version of an existing package, you should be able to do so using pull requests and someone with commit access will merge those PRs once CI passes. Sorry for the additional hassle.

Stefan

[Tony Kelman]

Even people with commit access should really go through PR's rather than direct pushes to METADATA (and base Julia too for that matter). Otherwise a mis-tag could cause Travis to start failing for unrelated innocent PR's. And new packages should really go through a bit of name bikeshedding/review even if authored by an established contributor.

[Milktrader]

Any chance of a day pass for when package developers have a flurry of tags? 

I'm not sure if this is possible, but a restricted privileges setup would be nice, where package developers are free to push updates, but not commit new packages, either others or their own. 

[Patrick O'Leary]

Ultimately, a homu-like GitHub bot (http://homu.io/) could autocommit certain METADATA changes--I think this has been discussed, but no one has had the opportunity to set something up.

[Stefan Karpinski]

I think this is the best approach: automerging PRs that pass CI and only introduce new versions of existing packages or change the requirements of existing versions.

[Simon Kornblith]

(and are submitted by someone with commit access to the package's repository)

[to...@kelman.net]

We should probably do an automated system for the future more open namespaced metadata, but even version bumps within the "curated" subset should require at least minimal human review as a sanity check against obviously broken or malicious code.

[Tom Breloff]

@tkelmen: Agreed.  There's also the issue of security.  I was surprised to see so many people with major commit access that don't even have two-factor authentication turned on.

[Stefan Karpinski]

On Tue, Sep 15, 2015 at 2:41 PM, Simon Kornblith <si...@simonster.com> wrote:

(and are submitted by someone with commit access to the package's repository)

Right, that's a fairly important criterion. PRs that don't meet this can be merged but should be merged manually.