On 10/29/2014 09:47 AM, Indrek Altpere wrote:
Well, indeed, but is this really a good target to strive for and bring out as an example? The 4 patches add only a number of tests that verify difference between wine and windows UTF-7 encoding, missing stuff is marked as wine_todo, testbot has marked them as passing (meaning todo_wine marked tests are expected to fail on current wine and do so and same tests are supposed to pass on windows and do so), no actual implementation that would change the behavior of wine itself. So unless there is something wrong with the coding style (which hasn't been commented on after the last patches), shouldn't such patches (only tests, verified as valid by testbot) get included a lot faster than 10-30 days??
Regards, Indrek Altpere
Keep in mind that developers time is very scarce because they (amongst many other tasks) : - read bugzilla reports - install the app, trigger the bug - scratch some patch to aid debugging - test expected behavior on windows machines (real or virtual) - refine their patch - check for non-regression with the testbot - sometimes, ask for comments on wine-devel but they also - read patches from the patch queue when they are confident in this wine area (check coding style, variable names, logic, error handling...) - test and comment them - read technical specifications - write lengthy e-mails when things are complicated
AJ is doing all of that *plus* he manages his team and manages *all the* patches queue
They are doing that every day for many years and even if it's perfectible, don't waste their precious time and stop whining
Please be patient, if nothing happens, try doing a more convincing argument (add tests, reference bug id you solve...) and finally, resend your patch