rebase before merge is a good practice/gate used by other code review tools (like gerrit).
it helps to keep git history linear (less merge commits) and takes the most recent patch set from PR and have it rebased onto the tip of the destination branch. If rebase succeeds (no conflicts) - jenkins will smoke-test it and RM will feel more confident that rebased PR is up to date with smoke testing and operational/compilable state. smoketest/jenkins is not competing with mtt or other forms of testing anyway, just brutal indication of project health. :) On Thu, Feb 5, 2015 at 9:17 PM, Jeff Squyres (jsquyres) <jsquy...@cisco.com> wrote: > Thinking about this a little bit, there's a wrinkle: you (the individual > developer) will need to give push permissions on your ompi / ompi-release > fork to the OMPIBot Github account. Otherwise, it won't be able to push > back to your fork. > > Thinking about this even more, I'm a little worried about implementing > this feature. It seems to give a lot of credence to the smoke test -- > i.e., if hello world/ring work, then my patch must work. I'm not sure > that's "enough" to give me confidence that a patch rebased properly. > > Thoughts? > > > > On Feb 5, 2015, at 2:08 PM, Jeff Squyres (jsquyres) <jsquy...@cisco.com> > wrote: > > > > Mike: > > > > This sounds good, but let us get the label/milestone/assign thing going > first. > > > > I'm thinking that the functionality you describe may become a different > bot...? I'm not sure. > > > > > >> On Feb 5, 2015, at 9:56 AM, Mike Dubman <mi...@dev.mellanox.co.il> > wrote: > >> > >> yep, exactly. > >> > >> > >> On Thu, Feb 5, 2015 at 2:35 PM, Jeff Squyres (jsquyres) < > jsquy...@cisco.com> wrote: > >> On Feb 5, 2015, at 7:20 AM, Mike Dubman <mi...@dev.mellanox.co.il> > wrote: > >>> > >>> sounds cool and useful. > >> > >> K, thanks. > >> > >>> Also, does it make sense to have "rebase" knob to cause "try rebase if > no conflicts" with upstream? > >> > >> Just to be sure what you mean: something like "rebase:" that will cause > the patch set to be rebased to head of master (if there are no conflicts)? > >> > >> I think you're asking because: > >> > >> - it doesn't make the RM/GK's job easier because github would have > already detected this and still kept the "merge" button green on the PR > >> - but it would (assumedly) trigger a new Jenkins smoke test, which is > the desirable thing here (i.e., it may merge, but it may or may not *work) > >> > >> Is that what you're thinking? > >> > >> -- > >> Jeff Squyres > >> jsquy...@cisco.com > >> For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > >> > >> _______________________________________________ > >> 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/02/16929.php > >> > >> > >> > >> -- > >> > >> Kind Regards, > >> > >> M. > >> _______________________________________________ > >> 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/02/16934.php > > > > > > -- > > Jeff Squyres > > jsquy...@cisco.com > > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > > _______________________________________________ > > 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/02/16941.php > > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > 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/02/16943.php > -- Kind Regards, M.
