Hi Dave,
> The other way to solve this issue would be to stop treating the master as > a general dumping ground for potentially unstable code where anyone can > just push any time they want. If we switched to using PRs for > (essentially) all code that goes into master as well, then we wouldn't need > two different sets of permissions. > hear hear - I think once we have more than just the MLNX jenkins testing every PR we should definitely move to this approach and yes for master. I'm confident that PRs will be going through a smoke test on the Cray XC systems by the end of the week. If it were up to me, I'd only allow the most trivial of commits to bypass the PR process. I think we're gradually getting there as it is. Hopefully by the developers workshop in June, we'll have at least 2 if not 3 or more jenkins testing PRs. It will be pretty indefensible at that point to permit a bypass of the PR process for master. It would also be easy to trap the I-want-to-bypass-PR-because-I know-what-I'm-doing-developer with a second level of protection. Just set up a jenkins project that does a smoke test after ever commit to master. If the smoke test fails, send a naughty-gram to the committer and copy devel. Pretty soon the developer will get trained to use the PR process, unless they are that engineer I've yet to meet who always writes flawless code. Howard > > Back in the SVN days it was nice to have a trunk where people could freely > check in work because there was no other good system for keeping track of > your own work or sharing it with others. But with Git we no longer have > those problems. I can easily organize multiple concurrent streams of > private development, avoid losing work, and share work with others, all > without committing to some centralized master branch. > > -Dave > > _______________________________________________ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2015/05/17419.php >