[GSoC] Project proposal : Winetest Scripting Interface

[Yash Yadav]

Hey Stefan,

A big thanks for dedicating some time of your schedule to check out a 
proposal which has absoluely no chance of being selected.

About the idea in the suggested list, I'd agree that the discussion in 
the IRC gave me a different picture of the project compared to what I 
thought of after reading on the website. Good all the way, indeed the 
idea is interesting and comparatively more closer to my strengths than 
other projects.

And yes, You're right, I had not tried out the testsuite then. I 
should've had. But I wonder what was I thinking when I wrote that 
<quoted> part of the proposal. I have compiled and installed wine from 
source before and am aware "make install" certainly wouldn't test it 
there. Ugh, mistake.

As I write this I just ran "make test" from the source root. Test fails 
at bcrypt dll test, heap allocation errors I guess. The output pattern 
from this single run seems catchable though. I thought tests would 
return huge paragraphs of texts for each test (oh what the hell was I 
thinking), what turned out were lines of fixme/errs just like the ones 
that show up on a regular program run. The single lined fixme/err(s) 
seem easier to filter compared to what I was imagining. xD

Thanks again for this feedback, I feel great for my first attempt. Great 
because I didn't think this proposal would be one of the "more 
selectable" ones. It was my first attempt. I was confused myself of 
whether my proposal makes sense or not. This has been a good experience 
for me and as I have not submitted any patch to wine so I have less to 
regret now as I would've lost it anyway I guess. My main target next is 
to figure out how to catch problem areas in huge code bases. Might as 
well try to fix a wine bug sometime, thats a priority for summers. I'm 
likely to show up in the IRC in the middle of the summers. :)

I'm CC'ing this into the mailing list as I usually like to keep things 
public (except personal things which are supposed to be undercovered). I 
already have opened my proposal into the mailing list. I have the IRC 
conversation of us which explained the winetest scripting interface idea 
to a better extent, I'm not sure if I should publicize it here for 
future references. I'll keep it unless required.

I wish good luck for my fellow students and the organization to get the 
right set of contributors.

Yash Yadav


On 04/01/2018 03:03 PM, Stefan Dösinger wrote:
> Hi Yash,
>
> As promised here is my take on the merits of your proposal for future 
> use. In short, I'd give it a thumbs up, but I am usually easier to 
> convince than other Wine mentors. Whether we would have accepted it 
> would also depend on what other proposals we could choose from and how 
> many slots we'd get.
>
> A big problem is that the idea (which I proposed on the idea list) is 
> somewhat poorly defined. It isn't a clear "code to spec" task, but 
> involves a lot of talking to other projects and investigating how 
> their test suite and development workflows work. Your proposal 
> accounts for that, which is great! You had good interaction with us on 
> IRC and discussed your ideas early, which is also a big plus. Of 
> course success or failure are partially in those 3rd party project's 
> hands. If we never get a proper reply from them the GSoC project would 
> be doomed to failure.
>
> If time permits I'd like to talk to the Mesa devs and ask them what 
> would be necessary for them to run our testsuite on a regular basis. 
> Of course so many priorities need attention :-\ . But my default 
> action will be to remove the idea from the suggested idea list for 
> next year.
>
> I am not sure if you have run the Wine tests yet - "Code the initial 
> version of the script that would run the “make install” in selected 
> directories depending upon the type of test that is called in for" 
> suggests you maybe did not, because running "make install" is not 
> required to run the tests. In fact you can run all of Wine out of the 
> source tree, which is much more comfortable when you're working on the 
> code. Just run "make" to build it and run it from ~/path/to/built/wine 
> foo.exe . No sudo, no copying of megabytes of files. The canonical way 
> to run the tests is "make test", which you can run on the top level 
> directory, or in a subdirectory, e.g. dlls/d3d9/tests. There's 
> programs/winetest/, which is a comfortable way to copy one binary to 
> another computer and run the tests.
>
> The "make install" thing wouldn't be a reason for me to reject the 
> proposal. It might be a case of poor phrasing, language 
> misunderstanding, etc. That's where the requirement to send a patch is 
> handy - if you manage to build Wine, make a small patch, commit it to 
> your git tree and send it to the mailing list we know you're competent 
> enough to figure out the difference between "make install" and "make 
> test" quickly.
>
> I hope I could shed some light on the magic of GSoC applications and 
> give you something for your effort to write the proposal despite the 
> deadline screwup. However, what I've written is just my opinion. Since 
> I'd mentor such a project it would carry a lot of weight, but it isn't 
> the the only thing that matters. Projects other than Wine may look at 
> completely different things.
>
> Feel free to quote this E-Mail on the mailing list. The things we look 
> for in proposals aren't a secret. But because this was your proposal 
> I'm sending this in a private mail to you to give you a choice what to do.
>
> Best regards,
> Stefan