Hi Yash,

It seems like you submitted your draft proposal alright, but you didn't submit your final proposal before the deadline. This means that we cannot accept it unfortunately :(
Don't fret though. You can always stay and contribute to Wine and apply during your final year. This can increase your chances of getting accepted next time :)

Cheers,
Aaryaman

On Thu, Mar 29, 2018 at 6:48 PM, Stefan D������singer <stefandoesinger@gmail.com> wrote:
Hello Yash,

It seems your E-Mail got stuck in moderation until yesterday, I've only seen it today - That's most likely because you are not subscribed to the mailing list. Unfortunately you did not post it on������summerofcode.withgoogle.com, and we can not accept it without the proposal being there :-( . Posting proposals for public discussion on the mailing list is highly encouraged, but not the official GSoC place.

I'll send you another E-Mail over the weekend to comment on the merits of the proposal so you have at least some feedback should you choose to apply for GSoC in the future.

Best regards,
Stefan


Am 26.03.2018 um 08:02 schrieb Yash Yadav <yashdimpu@gmail.com>:

Hi,
I am Yash Yadav and this is my first proposal for the GSoC idea "Winetest Scripting Interface".
Please excuse the delay and me doing this near the deadline.

Winetest������Scripting������Interface

Abstract

Wine(Wine������is������not������an������emulator)������depends������on������multiple������different������third������party������projects������which������are������mostly������drivers������or������low-level������system������programs������that������allow������wine������to������convert������and������forward������windows������calls������into������POSIX-compliant������environment.������Example������supporter������projects������:������openal-soft,������gecko,������mesa,������etc.
Having������dependency������on������multiple������third������party������projects������naturally������brings������in������the������trouble������of������keeping������track������of������what������the������other������projects������are������doing.������To������make������things������easier,������wine������has������testsuite������that������could������be������run������by������the������third������party������developers������(graphics������drivers������devs������for������example)������to������catch������problems������their������own������tests������do������not������see.
The������problem������is������that������with������existing������testsuite,������the������reports������are������not������specific������enough������to������count������on,������as������they������only������report���������������success���������������or���������������failures���������������on������completion/termination.������This������leaves������developers������to������debug������by������manually������going������through������the������output������of������the������tests������in������terminal,������which������is������not������really������feasible������as������ignorable������failure������reports������would������be������crowding������all������the������output.

Why������This������Project

Being������an������avid������user������of������wine(Mostly������for������games������though)������from������the������day������I������shifted������to������linux,������I���������ve������always������wanted������to������contribute������to������the������project������since������wine������has������space������for������infinite������contribution������until������it������reaches������the������state������where������everything������of������windows������would������run������on������a������non������microsoft������kernel.������Thanks������to������GSoC������and������a������project������I������love,������I������can������go������up������there������taking������baby������steps������from������now.
This������project������has������a������good������scope������of������improving������wine������development������process������by������helping������other������projects������that������wine������runs������on.������For������a������beginner������contributor������like������me,������this������seems������to������be������a������better������start������at������getting������familiar������with������wine������codebase������compared������to������just������jumping������into������the������core.

Project������Goals

The������project������revolves������around������development������of������script(s)������that������enhance������the������functionality������of������the������existing������wine������testsuite.
The������idea������is������to������write������a������script������that������runs������wine������tests������keeps������a������track������of������reports������of������tests������over������different������patches������and������filter������out������new������failures������compared������to������previous������reports.
The������script(s)������would������be������written������with������non-wine������developers������in������mind.������Designed������to������be������run������by������the������developers������of������other������projects������that������wine������depends������on.

������

The������script(s)������would������:
1.������Report������more������sensible������information������than������just������reporting���������������Failure���������������or���������������Success���������������or������leaving������the������testers������with������lines������and������lines������of������test������results������that������they������should������be������ignoring.������(This������could������be������done������by������backtracking������a������little������from������the������failure������point.)
2.������Filter������out������the������new������failures������only������that������show������up������with������new������code������changes.
3.������Know������what������all������errors������are������ignorable������and������need������not������crowd������up������the������reports.
4.������Allow������running������tests������specific������to������the������section.������(Sound������testing������wont������run������graphics������tests)

Implementation

Target������is������to������write������the������script������in������python������3������since������I���������m������more������fluent������in������python������as������compared������to������other������scripting������languages.������If������python������is������not������allowed,������I���������ll������go������with������Bash������shell.
If������database������is������used������at������a������later������point,������I���������m������planning������to������go������with������sqllite3������or������Pandas������python������library������if������csv(comma������separated������values)������is������considered.

������

The������project������implementation������is������expressed������in������the������Timeline������section.

Timeline

Pre������GSoC������:������Community������Bonding������|������April������24������-������May������13

Get������acquainted������with������the������code������base������of������wine������and������the������test������suite.������Also,������discuss������with������the������team������of������what������exactly������needs������to������be������done������and������who������all������can������be������helpful������besides������the������mentor.

Week������1������|������May������14������-������May������20

Understand������the������relevant������parts������of������the������testbot.winehq.org������code������base������and������try������to������figure������out������how������the������existing������structure������works������on������windows.������Try������out������the������testsuite.

Week������2������|������May������21������-������May27

Try������out������the������existing������testsuite������for������different������versions������of������the������supporting������projects(the������ones������that������wine������depends������on)������and������record������patterns������in������the������output������from������the������testsuite.������Design������the������workflow������for������the������script(s).������Essentially������figuring������out������to������the������minute������details,������i.e.������the������dataset������and������the������information������that���������s������important������from������the������test������reports.

Week������3������-������4������|������May������28������-������June������10

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.������Then������add������support������to������catch������data������from������the������output������of������the������individual������tests.

Week������5������|������June������11������-������June������15

Phase������1������evaluation.

Week������5������-������8������|������June������16������-������July������8

Extend������script������to������filter������out������the������raw������data������from������the������reports������to������gather������important������information,������(the������points������relative������to������the������failure).������This������may������require������backtracking������from������a������failure������point������or������just������the������failure������report������for������the������particular������test������thats������running.������(This������is������to������be������decided������after������running������the������tests������manually������and������understanding������the������patterns,������week������2������work).
Result������out������useful������data������from������the������test������reports.������Also,������add������a������script������to������check������if������the������report������is������new������or������is������repeated.������This������would������require������use������of������database������or������csv(comma������separated������values)������unless������suggested������otherwise.

Week������9������|������July������9������-������July������13

Phase������2������evaluation.

Week������9������-������11������|������July������14������-������July������29

Filter������out������the������edge������cases������and������test������the������script������itself������for������undesired������output������or������working.������Work������on������the������back-end������(preferably������the������database������that������would������store������the������results).������Add������another������script������to������obtain������the������data������as������required.������(Date������wise/patchset/commit������wise).������See������if������it���������s������possible������to������integrate������the������data������fetching������script������into������the������testbot������website������to������display������the������reports������timeline.

Week������12������-������13������|������July������30������-������August������14

Fix������bugs,������clean������the������code.������Write������documentation������for������the������script(s).������Final������evaluation.

������

The������API

The������script(s)������would
*������Keep������the������test������reports������under������version������control������system(preferably������GIT).������The������way������new������failures������or������bugfixes������can������be������catched.
*������Only������show������the������relevant������data������to������the������failure������if������a������testcase������fails.������(May������require������backtracking������from������the������failure������point).
*������The������data������relevant������to������the������failure������would������also������help������in������keeping������track������of������previous������failures������and������keeping������a������timeline������of������tests.

About������Me

Name������:������Yash������Yadav
Email������:������yashyadav.710@outlook.com������|������yashdimpu@gmail.com
Telephone������:������+91������-������810-427-1666
Github������:������https://github.com/OhYash
Telegram������:������@OhYash
IRC������:������ohyash on������freenode������IRC
Country������of������Residence������:������India
Timezone������:������UTC������+������05:30

������

I������am������an������undergraduate������student������in������my������3rd������year������of������Bachelors������in������technology������in������Lovely������Professional������University,������in������Punjab,������India.
My������language������of������choice������is������C������but������I������frequently������choose������between������python������and������C������depending������upon������the������type������task������I������do.������I������have������been������using������git������for������the������past������one������year.

������

My������semester������would������end������on������21st������May������and������yes,������I������would������be������having������exams������within������that������period.������I������would������have������some������placement������preparatory������classes������in������June,������but������If������I������am������selected,������I������would������be������able������to������give������about������5-6������hours������everyday������in������weekdays������and������more(8-10)������on������weekends.