Add dotnet/wpf-test as submodule inside dotnet/wpf

[singhashish-wpf]

Problem

It is difficult for contributors to contribute to the test repo(wpf-test) and with test repo being different, contributors must create separate PRs in both the repos. Some contributors might not even be aware of the wpf-test repo and might also not have a reference on how to add the tests there. This creates problems of regression, untested code, and decreases the quality over time.

Proposed Solution

Create a git submodule of wpf-test repo in wpf repo, and contributors could create a single PR with product and test changes which will make it easier to review, thereby improving our tests as well as improving the quality.

Ask

I am looking for more ideas and thoughts regarding this approach or a better approach to improve test infra for wpf repo. Requesting suggestions and opinions, so that we can take the steps in the right directions. If we reach a consensus, we could follow that approach otherwise git submodule will be the way for us for now.

cc:// @dotnet/wpf-developers @dotnet/dotnet-wpf-triage @dotnet/dotnet-wpf-winforms-friends

[lindexi]

Can I ask why divided into two github repo? How about merge the wpf-test repo into this?

[singhashish-wpf]

This happened long before, I vaguely remember why this was done (I just joined when this was done). WPF test collateral is quite huge, only a portion of it has been migrated/open sourced to wpf-test. There were open sourcing hurdles which were required to be fixed and hence separating the two repos made sense to deliver these as separate milestones.

Merging the code directly is also a possibility, but it will also result in the huge size of the repo.
Git submodule might be a better way to do this.

[miloush]

I am worried about the size of the repo and you don't need the tests to compile and use WPF. A submodule sounds like a reasonable compromise.

[kant2002]

Personally I would like that project run as many tests as practically possible. Submodules make running tests much more complicated since that effectively become second class scenario.

[h3xds1nz]

I would prefer it being a single repo as well, not doing it as a submodule, it will only become more complicated then. Glad this is being considered.

dotnet/runtime has it in the same repo, it makes it easy to contribute and add own tests.

[miloush]

wpf-test is 1.5 GB and the test infrastructure is much more complex, including automated UI tests, which the runtime does not have. I wouldn't have high hopes this would increase PRs with tests. I am not sure how submodule makes running the tests more complicated, since part of the test run can be ensuring the submodule is cloned.

Either way, most people who contribute seem to be in favor of merging the repos. As long as it doesn't affect build times, I don't really have any good argument other than size.

[bgrainger]

Create a git submodule

IMO, this is never a solution, it just generates more problems. Most developers (in my experience) find git submodules unfamiliar and very cumbersome to work with.

First one has to know that you need to update the submodule when you pull code; this is often overlooked. Then, when making changes, you have to commit and push to the submodule's repository first. (Which would have to be a fork for external contributors, adding yet another layer of complexity.) Then you have to add the submodule change to your commit in the parent repo and push that at the same time. (I've never tried using submodules with GitHub repos I don't have "push" privileges to; hopefully one wouldn't need to change the git URL of the submodule to one's fork, but I've never tested.)

When the PR from the submodule gets accepted, it's typically rebased or squash-merged, which changes its SHA. Now the PR to the parent repo is out-of-date and has to be changed to reflect the new SHA.

Resolving merge conflicts is now much more difficult, because the conflict is just two different SHAs; you don't see what the change in the code is. (Perhaps GitHub has dramatically improved the UI since the last time I used submodules, and it's better now; again I haven't tested recently.)

IMO, this will result in extra work for contributors, will increase the number of PRs that are wrong (e.g., forgetting to commit the submodule change is a common failure), will make resolving merges harder, and overall increases the complexity of working in dotnet/wpf. I would strongly discourage you from choosing submodules as the way forward. Like other commenters have replied, merging the repo in seems like a much better approach.

[miloush]

I think the tooling got a bit better recently with VS being able to work with multiple repositories at once, but these are good points. There is also an option to keep the current status quo. If there is a concern of people not testing code, a policy can be put in place that PRs will not be merged without appropriate tests in place.