> Patches are included in .pol packages qparis. That is the problem. We are not as support people going to download a complete pol file to find out what patch is in it just to answer yes or no. Seeing the patch file does not tell us what wine bug it is covering. This is key when we access the wine bugzilla we may see that X bug is now closed and its merged into mainline since X version. Some of the worst issues of wine not fixing issues for ages have come from the fact of patches being lost as important and not linked to a new bug number. Yes we need to know if wine bugzilla says a patches requirement is closed. If its still being applied and required on a newer version than where is marked no longer required we have a issue needing a new bug number. Of course we as support people will not be impressed to find this the case since the maintainer of the pol should have been on top of bug status. At least if we know we can attempt to have it corrected. Really we need a short form that tells us exactly what has been applied. At worse 1 or 2 kb of information. Ie where the patches were from what bug number they are fixing. Also can be the case the patch as been updated. Avoid DRM would normally be a hack and what is required to make the DRM work would be the correct solution. Idea that patches included solve the problem is wrong. If the patch cannot be placed in wine bugzilla due to being a game cracking. Then that would be a true case of 100 percent sure not supported by wine and questionable on legal status in many countries. Yes some of the .pol's should be marked legally questionable and people should check there countries own legal requirements before using. Really DanKegel for simplest management wine bugzilla should be holding the patches. But for items outside that something like a github holding them so they can be accessed without downloading a full pol file would be useful. Lot of us who do support stress our download quotas enough without extra.
