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
-
Yash Yadav