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.