Re: Submitting additional pull requests

On Thursday, May 8, 2014 at 7:23, Jacob Rossi wrote:
> We're making great progress on getting pull request #324 reviewed and landed. Part of what's been a challenge, I think, is how big the PR is and that we keep tacking on more tests to the PR as they've been developed. 
> 
> There's a few more test assertions we've been working on and will submit soon. To avoid further delaying landing #324, I'd prefer these new tests get submitted as their own separate pull requests. The only problem with this is that these new test cases depend on pointerevent_styles.css and pointerevent_support.js, which are in #324. 
> 
> What's the best way to accommodate this? I can see a few options:
> 
> 1) Circumvent the review of #324, and go ahead commit the 2 common dependencies to w3c/web-platform-tests/master (I have write access to the W3C org). If there are issues with those files themselves, we can file issues on the W3C repo.
> 2) Include the latest version of the 2 dependencies (from #324) in a new pull request with the new tests
> 3) Branch from submission/Microsoft/PointerEvents (#324) into a new branch and make a new pull request from there.

If there is a history clean up scheduled for all the fix up commits (considering how big #324 is I personally would do a history rewrite to make the commit log cleaner), 2 could work as well. You can have the dependencies on both sides, and which ever lands first keeps it, while the one that lands later can be rebased (and cleaned up while doing so, ideally) onto master that has the patch with the dependencies already in there. (which means another PR, but you can comment that it's a already reviewed PR that's just been rebased)

If there are no plans to do a history clean up after the review is done 3 is probably "the most Github way" to do it. Downside is that commit log for w-p-t will be longer than Encyclopedia Britannica a couple years down the road with the all the work going on.

Sangwhan

Received on Thursday, 8 May 2014 02:03:25 UTC