Guys, you are way off-base here. This is why Jeff asked that we table this conversation until the devel meeting. As he and I discussed at length on the phone, your starting premise is incorrect.
This entire thread stems from Jeff’s recent attempt to do a bisect search on the master. He hit several points where the search failed due to apparent breaks in the master as opposed to the specific problem he was searching for. It was incorrectly assumed that this was because the master was actually broken at those points - however, as I pointed out to him, the master may well have been working…but not for the particular configuration and/or environment he was using. We rarely see people commit code that they know breaks the master. Instead, they commit code that works on their system, which is the only one they can test on, configured their way, and run in their normal manner (binding, mapping, etc). It subsequently turns out to break someone else’s environment and/or way of configuring and running. Nobody can predict that, and it is incorrect to be trashing our developers for such problems. Contrary to what you are saying in this thread, I actually believe we have pretty good people in this community. You may not have been intending to convey a different opinion, but it is coming across that way. Although it wasn’t based on Jenkins and Github PRs, we have tried similar approaches in the past, and they failed to produce the desired result. The simple problem is that we (a) don’t have the people to review every change prior to commit, and (b) every developer doesn’t have access to all environments. So the problem is that even the most conscientious developer would wind up playing blind man’s bluff with somebody else’s Jenkins server, trying over and over again to find the magic change that will make that system work - with no way to even test compile what they are attempting. None of us have the staff for that effort, and thus the result turns out to be just a way of preventing people from doing anything. Best we discuss this in person before folks get too carried away. Ralph > On May 19, 2015, at 10:40 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > > > On Tue, May 19, 2015 at 9:37 PM, Howard Pritchard <hpprit...@gmail.com > <mailto:hpprit...@gmail.com>> wrote: > 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. > > I've never met that developer, either. > However, I have met one (and thankfully only one) who doesn't give a > [expletive-deleted] how many naughty-grams their work generates. > They just keep on doing exactly what they think is right (and complain that > nobody else in the organization knows how to get work done). > > -Paul > > > -- > Paul H. Hargrove phhargr...@lbl.gov > <mailto:phhargr...@lbl.gov> > Computer Languages & Systems Software (CLaSS) Group > Computer Science Department Tel: +1-510-495-2352 > Lawrence Berkeley National Laboratory Fax: +1-510-486-6900 > _______________________________________________ > 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/17429.php
