OK, so Travis does run. If it fails, will it be visible? Usually we notice because GitHub puts a red X by the PR. At that point, the PR is merged, so it won’t show up there. Will it show up in the list of commits for master? If so, I don’t know how often people check that.
I guess if the maintainer does a rebase at all, there is a chance for the PR code and the new master code to clash. There is nothing saying that after that first rebase, a new PR is merged that changes half the files. This could easily conflict with the PR we want to merge. So we’re trying to walk a tightrope between having the dev rebase constantly to travis failing on master. If travis fails on master, it will fail for all other PRs. This will halt merges into master until @subhasisb fixes it (he owns the repo and is the only person who can force push to master).
I guess that’s the question that needs an answer. How much risk are we willing to take? One one side we have the ease of use and gain of productivity by not requiring constant rebasing (some 12 hrs apart). On the other side we have the risk of the productivity loss of our project being down until @subhasisb has the time to fix it.
With all that said, I think I am now agreeing with @subhasisb. It needs to be a judgement call on the side of the maintainer. If we have a small PR like a 3 line change to a test, the maintainer can merge it directly. If it is a larger PR, the maintainer can have the developer rebase.