1/7, 2/7, and 4/7 add dead code, and I cannot easily guess how 1/7 and 2/7 will be used.1/7, 2/7, and 4/7 add dead code, and I cannot easily guess how 1/7 and 2/7 will be used.
1/7 and 2/7 is used here: https://gitlab.winehq.org/wine/wine/-/merge_requests/3303/diffs?commit_id=cb...
In general, if a patch introduces some new code, it should be justified by the patch itself. That means that, in principle, no patch should introduce dead code, period.
Of course, it gets tricky when you have a large patch that you'd like to split up for reviewability. In that case it may be fine to split up the patch. But if that's going to happen, I'd assert that (a) it should be done in the same series as its user, (b) it should be justified in the patch subject. Reviewers in general are going to read one patch at a time; looking forward should be avoided, especially implicitly.
7/7 does not at all do what it says it does.
Any suggestion on 7/7? Change the commit message or split into 2 patches?
From skimming, it seems to do three things:
* Add CLSID_MFMPEG4SinkClassFactory, which is most of the patch;
* actually introduce the wg_container_type enumeration, which is a scant few lines and should probably be deferred until it's actually going to be interpreted;
* add wg_container_type_to_caps(), which is currently dead code and should definitely be deferred until it's actually going to be used.