{"thread":{"id":"61211","subject":"Fwd: [GSOC][Proposal] Move existing tests to a unit testing framework","startedAt":"2024-03-27T14:36:14Z","lastAt":"2024-04-02T10:19:29Z","messageCount":6,"participants":["Sanchit Jindal","Patrick Steinhardt","Kaartic Sivaraam"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"491696","messageId":"CAN7Jk_0hyjx39rrO1PKbEcJQXLtCYkWP7A4mCv01DZu2ffGHyw@mail.gmail.com","threadId":"61211","inReplyTo":"CAN7Jk_2mMiVjXuF02S14OX6Rjq2jVjNxcUbZvTqhcz_YMnD=gg@mail.gmail.com","subject":"Fwd: [GSOC][Proposal] Move existing tests to a unit testing framework","fromName":"Sanchit Jindal","fromEmail":"sanchit1053@gmail.com","sentAt":"2024-03-27T14:36:06Z","receivedAt":"2024-03-27T14:36:14Z","isPatch":false,"sender":{"key":"sanchit1053@gmail.com","avatar":null},"body":"Hello,\n\nPlease find my proposal for GSOC 2024 for the project \"Move existing\ntests to a unit testing framework\" at\nhttps://docs.google.com/document/d/1yWP5GFRksdQEOKtYIEXbNSVb1qlJ2szRvpTcXXVvgTk/edit?usp=sharing.\nI am also adding the text version for convenience.\n\nThank You,\nSanchit Jindal\n--------------------\n\nGoogle Summer Of Code Proposal\n\nGIT (Move existing tests to a unit testing framework)\n\n### Personal Information\n\nName:          Sanchit Jindal\nEmail:         sanchit1053@gmail.com\nQualification: B.Tech in Computer Science and Engineering\n\n\nGreetings,\n\nMy name is Sanchit Jindal, currently pursuing my B.E. in Computer\nScience at the Indian Institute of Technology, Bombay, I will complete\nmy degree in May 2024. I am writing to put forward my proposal for the\nGit Project to transition the unit tests to the new Unit Testing\nFramework.\n\nYou can find my Resume at\nhttps://www.linkedin.com/in/sanchit-jindal-0a953621a/ in the featured\nsection\n\n\nThroughout my academic journey and internships, I've gained valuable\nexperience across diverse domains, ranging from machine learning to\nfundamental system components like compilers and operating systems.\nThis breadth of exposure has honed my ability to swiftly grasp new\nconcepts and adapt to different codebases. Proficient in both C and\nC++, I am well-equipped to contribute effectively to the project.\n\nFor this GSOC project, I aspire to make meaningful contributions to\nthe open-source community. My interest in software development drives\nme to create solutions that will offer utility to others.\n\n\n### Overview\n\nProposed Abstract\nGit has a lot of test cases that need to be migrated to use a new unit\ntesting framework. This typically involves moving code from both:\n* a “t/helper/test-*.c” test helper in C, and\n* a “t/*.sh” test script in shell that invokes the test helper\n\n\nover to a single “t/unit-tests/t-*.c” in C using the unit testing framework.\n\n\n### Details\n\nThe Project entails porting the current testing framework (which is a\ncollection of helper files written in c that provide various\nutilities, and various shell scripts) to using a new Unit-Testing\nLibrary. The shell scripts in the original code base setup the\nenvironment and , using the helper functions, test the functionalities\nprovided by git. The new framework utilises the test-lib library that\nwill combine the functionality of both the helper functions and the\nshell scripts into one unit-test.\nAdvantages of this approach\n* Unit Tests are a great way to check any program and to test all\npossible corner cases and functions\n* Using this new testing framework will provide a more modular\napproach to unit testing, allowing to create more extensive tests, and\nto provide better debugging features. Such as better debug Messages or\na better CLI to choose and run tests.\n* The tests will also improve the runtime as instead of running\nmultiple process (with each use of shell commands), the program can\ncompile and run a single process\n* The approach will also future proof the unit testing as having a c\nlibrary will provide a better base than shell scripts to test\nlibraries and other internal features\n\n\n### Basic Structure of the Changes\n\n* For each file in the helper directory I will create a corresponding\nunit-test file. (Some files which are being used by multiple test can\nbe ported later)\n* Each test in the script will be corresponding to a function that\nwill be called in the format\n\n'''\nTEST(funtion_name(), “SUCCESS MESSAGE”);\n'''\n\n* The function body will contain the main implementation of the test\ncorresponding to the c file ( The helper function will ideally be the\nsame with no or minimal changes just to allow it to be called as\nrequired )\n* Where the assert usually given at the end of the test will be made\nusing the utility functions such as check_int, check_str and others,\n(or creating more function as they are required)\n* The Make files will be updated to remove the use of shell script\nwith compiling and running the new c programs\n\n### Previous Contributions\n\nI have worked on the micro-project\nUse test_path_is_* functions in test scripts\n\nThread Link: https://lore.kernel.org/git/b8d0620d4104106210ecf6a34ada591adf01cff8.1711049963.git.gitgitgadget@gmail.com/\nStatus: Open\n\nI had some difficulties in understanding the usage of gitgitGadget and\ngit send-email which are being employed as the Pull request\nalternatives. Having tried gitgitGadget I am confident that I will be\nable to utilise it hereafter. I am having some trouble using git\nsend-email with the network at my institute but I am optimistic that I\nwill be able to use it after the completion of my degree.\n\nWith the guidance of Eric Sunshine and Junio C Hamano, I have iterated\nthrough different versions of the pull request, and familiarised\nmyself with the git commit pattern and formalities\n\n\n### Deliverables\n\nThe plan is to port the helper functions from helper directory to the\nunit-test directory along with the test defined in the shell scripts.\nSome of the helper tools which have a more basic functionality and are\nbeing used by multiple test scripts can be left untouched.\nAs a stretch goal I will try to port the shell scripts to the new\ntesting interface creating new functions for the library as required\nI also plan to keep documenting all the changes made and to keep in\nconstant contact with the mentors regarding any bugs or reviews\nregarding the code.\n\n\n### Availability\n\nI am expecting to be free from my academic responsibilities by 4th\nMay. I have no further commitments for the summer and will be able to\nprovide about 40-50 hours of work per week. I am confident that I\nshould be able to complete about 2-3 files each week depending on the\nfiles.\n\n\nRelated Work\nThe project has been worked on by Achu Luma for the Outreachy Internship\nTest-ctype:\nhttps://lore.kernel.org/git/20240112102743.1440-1-ach.lumap@gmail.com/#t\nTest-advise:\nhttps://lore.kernel.org/git/20240112102122.1422-1-ach.lumap@gmail.com/\nTest-data:\nhttps://lore.kernel.org/git/20240205162506.1835-2-ach.lumap@gmail.com/\nTest-hash:\nhttps://lore.kernel.org/git/20240229054004.3807-2-ach.lumap@gmail.com/\nTest-strcmp-offset:\nhttps://lore.kernel.org/git/20240310144819.4379-1-ach.lumap@gmail.com/\n\n\nAnother testcase has also been handled by Ghanshyam Thakkar\nTest–oid-array:\nhttps://lore.kernel.org/git/20240223193257.9222-1-shyamthakkar001@gmail.com/\n\n\n\n\nTimeline (Tentative)\n\nCommunity Bonding\n(1 May- 26 May)\nBe in contact with mentors and figure out the best way to migrate the\ntest-cases, Familiarise myself with the library and previous work done\nduring the outreachy program.\n\nPhase I\n(27 May - 11 July)\nBegin tackling the harder or longer testcases that will require more\nknowledge of the implementation\n\nPhase II\n(12 July - 18 Aug)\nKeep working on the testcases following the mentors feedback\n\nFinal Week\n(19 Aug - 26 Aug)\nFinish up the remaining testcases, fixing any bugs that may be\ndiscovered in the earlier implementations\n\n### Acknowledgement\nI would like to thank Eric Sunshine and Junio C Hamano for helping me\nwith the microproject and for the guidance on the gitgitGadget and git\nsend-email features, And also helping me get acquainted with the git\nPR guidelines.\n\nRegards\nSanchit Jindal\n"},{"id":"491723","messageId":"ZgUdKU5uynGrJ33f@tanuki","threadId":"61211","inReplyTo":"CAN7Jk_0hyjx39rrO1PKbEcJQXLtCYkWP7A4mCv01DZu2ffGHyw@mail.gmail.com","subject":"Re: Fwd: [GSOC][Proposal] Move existing tests to a unit testing framework","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2024-03-28T07:32:57Z","receivedAt":"2024-03-28T07:33:05Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Wed, Mar 27, 2024 at 08:06:06PM +0530, Sanchit Jindal wrote:\n> Hello,\n> \n> Please find my proposal for GSOC 2024 for the project \"Move existing\n> tests to a unit testing framework\" at\n> https://docs.google.com/document/d/1yWP5GFRksdQEOKtYIEXbNSVb1qlJ2szRvpTcXXVvgTk/edit?usp=sharing.\n> I am also adding the text version for convenience.\n\nThanks a lot for your proposal!\n\n> Thank You,\n> Sanchit Jindal\n> --------------------\n> \n> Google Summer Of Code Proposal\n> \n> GIT (Move existing tests to a unit testing framework)\n\nSorry to be nitpicky, but it's spelled \"Git\", not \"GIT\" :)\n\n> ### Personal Information\n> \n> Name:          Sanchit Jindal\n> Email:         sanchit1053@gmail.com\n> Qualification: B.Tech in Computer Science and Engineering\n> \n> \n> Greetings,\n> \n> My name is Sanchit Jindal, currently pursuing my B.E. in Computer\n> Science at the Indian Institute of Technology, Bombay, I will complete\n> my degree in May 2024. I am writing to put forward my proposal for the\n> Git Project to transition the unit tests to the new Unit Testing\n> Framework.\n> \n> You can find my Resume at\n> https://www.linkedin.com/in/sanchit-jindal-0a953621a/ in the featured\n> section\n\nI would recommend to include highlights of your resume in the proposal\ndirectly, either instead or in addition to linking to it. Not everyone\nhas a LinkedIn account (I don't), and thus I'm unable to view most of\nyour profile.\n\nIf you already did that, then it might be worthwhile to point out that\nyou did include highlights already. Otherwise I'm left wondering whether\nI miss out on any important information.\n\n> Throughout my academic journey and internships, I've gained valuable\n> experience across diverse domains, ranging from machine learning to\n> fundamental system components like compilers and operating systems.\n> This breadth of exposure has honed my ability to swiftly grasp new\n> concepts and adapt to different codebases. Proficient in both C and\n> C++, I am well-equipped to contribute effectively to the project.\n> \n> For this GSOC project, I aspire to make meaningful contributions to\n> the open-source community. My interest in software development drives\n> me to create solutions that will offer utility to others.\n> \n> \n> ### Overview\n> \n> Proposed Abstract\n> Git has a lot of test cases that need to be migrated to use a new unit\n> testing framework. This typically involves moving code from both:\n> * a “t/helper/test-*.c” test helper in C, and\n> * a “t/*.sh” test script in shell that invokes the test helper\n> \n> \n> over to a single “t/unit-tests/t-*.c” in C using the unit testing framework.\n\nI guess these formatting issues here come from the fact that you copied\nthe text over from the linked doc? Not a huge issue in that case.\n\n> ### Details\n> \n> The Project entails porting the current testing framework (which is a\n> collection of helper files written in c that provide various\n> utilities, and various shell scripts) to using a new Unit-Testing\n> Library. The shell scripts in the original code base setup the\n> environment and , using the helper functions, test the functionalities\n> provided by git. The new framework utilises the test-lib library that\n\ns/git/Git\n\n> will combine the functionality of both the helper functions and the\n> shell scripts into one unit-test.\n> Advantages of this approach\n> * Unit Tests are a great way to check any program and to test all\n> possible corner cases and functions\n> * Using this new testing framework will provide a more modular\n> approach to unit testing, allowing to create more extensive tests, and\n> to provide better debugging features. Such as better debug Messages or\n\ns/Messages/messages\n\n> a better CLI to choose and run tests.\n> * The tests will also improve the runtime as instead of running\n> multiple process (with each use of shell commands), the program can\n> compile and run a single process\n> * The approach will also future proof the unit testing as having a c\n> library will provide a better base than shell scripts to test\n> libraries and other internal features\n\nI wouldn't necessarily say \"better\" here. It's not like the unit tests\nare expected to eventually replace all ouf our shell script tests. Those\ntest suites serve different purposes, and in general it is recommended\nto continue writing shell script tests. They exercise the code at the\nuser level and thus directly mirror the experience a user would have,\nwhich is generally more helpful than only asserting that one small part\nof the codebase works. You can kind of think of these as integration or\nend-to-end tests\n\nSo the unit testing framework isn't necessarily better or even preferred\nin the general case. But it does allow us to exercise low-level\nfunctionality or specific edge cases that were previously cumbersome to\ntest.\n\nSo I wouldn't say \"better\", but rather that those unit tests address a\ndifferent need than the scripts.\n\n> ### Basic Structure of the Changes\n> \n> * For each file in the helper directory I will create a corresponding\n> unit-test file. (Some files which are being used by multiple test can\n> be ported later)\n\nNot all files in the helper directory are actually unit tests. Some of\nthem are, some of them expose functionality that would otherwise not be\nexposed by Git in a direct way. \"test-tool refstore\" comes to mind,\nwhich allows you to munge the ref store in ways that git-update-ref(1)\nwouldn't allow you to do. There are others.\n\nFurthermore, it may not be realistic to port _all_ existing tests over\nto the new functionality. It is perfectly fine to say that you plan to\nonly address a subset of unit tests, and you don't necessarily have to\nsay which ones exactly you want to port over now.\n\n> * Each test in the script will be corresponding to a function that\n> will be called in the format\n> \n> '''\n> TEST(funtion_name(), “SUCCESS MESSAGE”);\n> '''\n> \n> * The function body will contain the main implementation of the test\n> corresponding to the c file ( The helper function will ideally be the\n> same with no or minimal changes just to allow it to be called as\n> required )\n\nWith \"helper function\" you probably mean the test logic, right? I guess\nit depends on the function whether it would be ideal to have only\nminimal changes. Given that we also convert them to use our new testing\nframework I do expect that some of them may change significantly, which\nwouldn't be all that bad, either.\n\n> * Where the assert usually given at the end of the test will be made\n> using the utility functions such as check_int, check_str and others,\n> (or creating more function as they are required)\n> * The Make files will be updated to remove the use of shell script\n> with compiling and running the new c programs\n> \n> ### Previous Contributions\n> \n> I have worked on the micro-project\n> Use test_path_is_* functions in test scripts\n> \n> Thread Link: https://lore.kernel.org/git/b8d0620d4104106210ecf6a34ada591adf01cff8.1711049963.git.gitgitgadget@gmail.com/\n> Status: Open\n> \n> I had some difficulties in understanding the usage of gitgitGadget and\n> git send-email which are being employed as the Pull request\n> alternatives. Having tried gitgitGadget I am confident that I will be\n> able to utilise it hereafter. I am having some trouble using git\n> send-email with the network at my institute but I am optimistic that I\n> will be able to use it after the completion of my degree.\n\nWhile many folks use git-send-email(1) directly it is perfectly fine if\nyou don't and want to use GitGitGadget instead. As long as you are\nfamiliar with one of those workflows you don't necessarily have to set\nup the other one.\n\n> With the guidance of Eric Sunshine and Junio C Hamano, I have iterated\n> through different versions of the pull request, and familiarised\n> myself with the git commit pattern and formalities\n> \n> \n> ### Deliverables\n> \n> The plan is to port the helper functions from helper directory to the\n> unit-test directory along with the test defined in the shell scripts.\n> Some of the helper tools which have a more basic functionality and are\n> being used by multiple test scripts can be left untouched.\n> As a stretch goal I will try to port the shell scripts to the new\n> testing interface creating new functions for the library as required\n> I also plan to keep documenting all the changes made and to keep in\n> constant contact with the mentors regarding any bugs or reviews\n> regarding the code.\n> \n> \n> ### Availability\n> \n> I am expecting to be free from my academic responsibilities by 4th\n> May. I have no further commitments for the summer and will be able to\n> provide about 40-50 hours of work per week. I am confident that I\n> should be able to complete about 2-3 files each week depending on the\n> files.\n\nI would like to caution you a bit about the \"2-3 files each week\" goal.\nThe Git project is comparatively slow-moving, and it very often takes\nmultiple weeks for a patch series until it lands in the \"master\" branch.\nFurthermore, the quality bar is quite high in the Git project, which may\nrequire you to undergo several revisions for a patch series before it is\naccepted.\n\nSo I would recommend to account for all these facts. It may make sense\nto compare to below related work as an estimate of how much work you can\nget done realistically.\n\n> Related Work\n> The project has been worked on by Achu Luma for the Outreachy Internship\n> Test-ctype:\n> https://lore.kernel.org/git/20240112102743.1440-1-ach.lumap@gmail.com/#t\n> Test-advise:\n> https://lore.kernel.org/git/20240112102122.1422-1-ach.lumap@gmail.com/\n> Test-data:\n> https://lore.kernel.org/git/20240205162506.1835-2-ach.lumap@gmail.com/\n> Test-hash:\n> https://lore.kernel.org/git/20240229054004.3807-2-ach.lumap@gmail.com/\n> Test-strcmp-offset:\n> https://lore.kernel.org/git/20240310144819.4379-1-ach.lumap@gmail.com/\n> \n> \n> Another testcase has also been handled by Ghanshyam Thakkar\n> Test–oid-array:\n> https://lore.kernel.org/git/20240223193257.9222-1-shyamthakkar001@gmail.com/\n> \n> \n> \n> \n> Timeline (Tentative)\n> \n> Community Bonding\n> (1 May- 26 May)\n> Be in contact with mentors and figure out the best way to migrate the\n> test-cases, Familiarise myself with the library and previous work done\n> during the outreachy program.\n> \n> Phase I\n> (27 May - 11 July)\n> Begin tackling the harder or longer testcases that will require more\n> knowledge of the implementation\n> \n> Phase II\n> (12 July - 18 Aug)\n> Keep working on the testcases following the mentors feedback\n\nNote that you'll not only get feedback from mentors, but also from the\ncommunity.\n\n> Final Week\n> (19 Aug - 26 Aug)\n> Finish up the remaining testcases, fixing any bugs that may be\n> discovered in the earlier implementations\n> \n> ### Acknowledgement\n> I would like to thank Eric Sunshine and Junio C Hamano for helping me\n> with the microproject and for the guidance on the gitgitGadget and git\n> send-email features, And also helping me get acquainted with the git\n> PR guidelines.\n\nPatrick\n"},{"id":"491971","messageId":"CAN7Jk_3Y+Ls2VjhQqzA3Ymy-WDv8nT+v5bzU2a1YGz+j89vPgw@mail.gmail.com","threadId":"61211","inReplyTo":"ZgUdKU5uynGrJ33f@tanuki","subject":"Re: Fwd: [GSOC][Proposal] Move existing tests to a unit testing framework","fromName":"Sanchit Jindal","fromEmail":"sanchit1053@gmail.com","sentAt":"2024-04-01T17:29:16Z","receivedAt":"2024-04-01T17:29:22Z","isPatch":false,"sender":{"key":"sanchit1053@gmail.com","avatar":null},"body":"Hello,\n\nThank you for the review and sorry for the late reply.\nI have made the required changes in the document and uploaded the pdf\nto GSOC webpage\n\nThank You,\nSanchit Jindal\n\n----------------------------------------------------------------------------------------------------\nGoogle Summer Of Code Proposal\nGit (Move existing tests to a unit testing framework)\n\nPersonal Information\nName:          Sanchit Jindal\nEmail:           sanchit1053@gmail.com\nQualification: B.Tech in Computer Science and Engineering\n\nGreetings,\n\nMy name is Sanchit Jindal, currently pursuing my B.E. in Computer\nScience at the Indian Institute of Technology, Bombay, I will complete\nmy degree in May 2024. I am writing to put forward my proposal for the\nGit Project to transition the unit tests to the new Unit Testing\nFramework.\n\n\nThroughout my academic journey and internships, I've gained valuable\nexperience across diverse domains, ranging from machine learning to\nfundamental system components like compilers and operating systems.\nThis breadth of exposure has honed my ability to swiftly grasp new\nconcepts and adapt to different codebases. Proficient in both C, C++\nand shell scripting, I am well-equipped to contribute effectively to\nthe project.\n\n\nIn my internship at Quadeye last summer I worked on building an\nefficient and user-friendly library for creating and maintaining\nnetwork connections. The project included building a layered\narchitecture with a modular approach, and C++ meta programming for\neasy transfer of any structure between nodes.\n\nI have also worked on an gdb extension to provide a front end to\ndisplay graphical structures in the program via a web application. The\nprogram aids in debugging pointer structures and to visualise the\nrun-time of the code.\n\nFor this GSOC project, I aspire to make meaningful contributions to\nthe open-source community. My interest in software development drives\nme to create solutions that will offer utility to others.\n\n## Overview\n\n### Proposed Abstract\n\nGit has a lot of test cases that need to be migrated to use a new unit\ntesting framework. This typically involves moving code from both:\n- a “t/helper/test-*.c” test helper in C, and\n- a “t/*.sh” test script in shell that invokes the test helper\n\nover to a single “t/unit-tests/t-*.c” in C using the unit testing framework.\n\n### Details\n\nThe Project entails porting the current testing framework (which is a\ncollection of helper files written in c that provide various\nutilities, and various shell scripts) to using a new Unit-Testing\nLibrary. The shell scripts in the original code base setup the\nenvironment and , using the helper functions, test the functionalities\nprovided by Git. The new framework utilises the test-lib library that\nwill combine the functionality of both the helper functions and the\nshell scripts into one unit-test.\nAdvantages of this approach\n- Unit Tests are a great way to check any program and to test all\npossible corner cases and functions\n- Using this new testing framework will provide a more modular\napproach to unit testing, allowing to create more extensive tests, and\nto provide more fine-grained tests when required.\n- Having a testing library also provides various other features such\nas better debug messages or a better CLI to choose and run tests.\n- The tests will also improve the runtime as instead of running\nmultiple process (with each use of shell commands), the program can\ncompile and run a single process\n- The approach will also future proof the unit testing as having a c\nlibrary will provide a better base than shell scripts to test\nlibraries and other internal features\n\n\n### Basic Structure of the Changes\n\nFor each file in the helper directory I will create a corresponding\nunit-test file. (Some files which are being used by multiple tests and\nimplement more general functionality may not be ported to the new\nlibrary)\nEach test in the script will be corresponding to a function that will\nbe called in the format\n\n`TEST(funtion_name(), “SUCCESS MESSAGE”);`\n\nThe function body will contain the main implementation of the test\ncorresponding to the c file ( The helper function will ideally be the\nsame with no or minimal changes just to allow it to be called as\nrequired )\nWhere the assert usually given at the end of the test will be made\nusing the utility functions such as check_int, check_str and others,\n(or creating more function as they are required)\nThe Make files will be updated to remove the use of shell script with\ncompiling and running the new c programs\n\n\n\n### Previous Contributions\n\nI have worked on the micro-project\nUse test_path_is_* functions in test scripts\nThread Link: https://lore.kernel.org/git/b8d0620d4104106210ecf6a34ada591adf01cff8.1711049963.git.gitgitgadget@gmail.com/\n\nStatus: Open\nI had some difficulties in understanding the usage of gitgitGadget and\ngit send-email which are being employed as the Pull request\nalternatives. Having tried gitgitGadget I am confident that I will be\nable to utilise it hereafter. I am having some trouble using git\nsend-email with the network at my institute but I am optimistic that I\nwill be able to use it after the completion of my degree.\n\nWith the guidance of Eric Sunshine and Junio C Hamano, I have iterated\nthrough different versions of the pull request, and familiarised\nmyself with the git commit pattern and formalities\n\n\n### Deliverables\n\nThe plan is to port the helper functions from helper directory to the\nunit-test directory along with the test defined in the shell scripts.\nSome of the helper tools which have a more basic functionality and are\nbeing used by multiple test scripts can be left untouched.\nAs a stretch goal I will try to port the shell scripts to the new\ntesting interface creating new functions for the library as required\nI also plan to keep documenting all the changes made and to keep in\nconstant contact with the mentors regarding any bugs or reviews\nregarding the code.\n\n\n### Availability\n\nI am expecting to be free from my academic responsibilities by 4th\nMay. I have no further commitments for the summer and will be able to\nprovide about 40-50 hours of work per week. I will try porting at\nleast one file per week, depending on the community feedback and the\npace of the development process.\n\n### Related Work\n\nThe project has been worked on by Achu Luma for the Outreachy Internship\nTest-ctype:\nhttps://lore.kernel.org/git/20240112102743.1440-1-ach.lumap@gmail.com/#t\nTest-advise:\nhttps://lore.kernel.org/git/20240112102122.1422-1-ach.lumap@gmail.com/\nTest-data:\nhttps://lore.kernel.org/git/20240205162506.1835-2-ach.lumap@gmail.com/\nTest-hash:\nhttps://lore.kernel.org/git/20240229054004.3807-2-ach.lumap@gmail.com/\nTest-strcmp-offset:\nhttps://lore.kernel.org/git/20240310144819.4379-1-ach.lumap@gmail.com/\n\nAnother testcase has also been handled by Ghanshyam Thakkar\nTest–oid-array:\nhttps://lore.kernel.org/git/20240223193257.9222-1-shyamthakkar001@gmail.com/\n\n\n### Timeline (Tentative)\n\nCommunity Bonding\n(1 May- 26 May)\nBe in contact with mentors and figure out the best way to migrate the\ntest-cases, Familiarise myself with the library and previous work done\nduring the outreachy program.\n\nPhase I\n(27 May - 11 July)\nBegin tackling the harder or longer testcases that will require more\nknowledge of the implementation\n\nPhase II\n(12 July - 18 Aug)\nKeep working on the testcases following the mentors and community feedback\n\nFinal Week\n(19 Aug - 26 Aug)\nFinish up the remaining testcases, fixing any bugs that may be\ndiscovered in the earlier implementations\n\n\n### Acknowledgement\n\nI would like to thank Eric Sunshine and Junio C Hamano for helping me\nwith the microproject and for the guidance on the gitgitGadget and git\nsend-email features, And also helping me get acquainted with the git\nPR guidelines.\n\nRegards\nSanchit Jindal\n"},{"id":"492017","messageId":"CA+ARAtq85UYD0_XxPPu2QnWQ5gjpSMrXkTO48DOYkfu5h_1NhQ@mail.gmail.com","threadId":"61211","inReplyTo":"CAN7Jk_3Y+Ls2VjhQqzA3Ymy-WDv8nT+v5bzU2a1YGz+j89vPgw@mail.gmail.com","subject":"Re: Fwd: [GSOC][Proposal] Move existing tests to a unit testing framework","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2024-04-02T06:16:32Z","receivedAt":"2024-04-02T06:16:44Z","isPatch":false,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"Hi Sanchit,\n\nOn Mon, Apr 1, 2024 at 10:59 PM Sanchit Jindal <sanchit1053@gmail.com> wrote:\n>\n> Thank you for the review and sorry for the late reply.\n> I have made the required changes in the document and uploaded the pdf\n> to GSOC webpage\n>\n\nThank you for submitting the proposal. I just noticed one\ninconsistency which I wanted\nto get a clarification on.\n\n> ### Availability\n>\n> I am expecting to be free from my academic responsibilities by 4th\n> May. I have no further commitments for the summer and will be able to\n> provide about 40-50 hours of work per week. I will try porting at\n> least one file per week, depending on the community feedback and the\n> pace of the development process.\n>\n\nYou have mentioned that you would contribute 40-50 hours per week. That means\nit would qualify as a \"Large\" size project according to Google's\ndefinition [1]. It\nseems you have mentioned the project size as \"Medium\" while submitting the same\nin the GSoC website. Have you done this intentionally considering any planned or\nforeseen unavailability? If so, kindly clarify the same in your\nproposal. If not and you do\nintend to contribute the said amount of time, make sure to adjust the\nproject time in the\nGSoC portal soon.\n\n[1]: https://developers.google.com/open-source/gsoc/faq#how_much_time_does_gsoc_participation_take\n\n--\nSivaraam\n"},{"id":"492032","messageId":"CAN7Jk_2ZQarqVHVCk6=AoUR3sQTFQrK7dfdETwpJvvrdxK6YdQ@mail.gmail.com","threadId":"61211","inReplyTo":"CA+ARAtq85UYD0_XxPPu2QnWQ5gjpSMrXkTO48DOYkfu5h_1NhQ@mail.gmail.com","subject":"Re: Fwd: [GSOC][Proposal] Move existing tests to a unit testing framework","fromName":"Sanchit Jindal","fromEmail":"sanchit1053@gmail.com","sentAt":"2024-04-02T08:50:02Z","receivedAt":"2024-04-02T08:50:07Z","isPatch":false,"sender":{"key":"sanchit1053@gmail.com","avatar":null},"body":"On Tue, 2 Apr 2024 at 11:46, Kaartic Sivaraam\n<kaartic.sivaraam@gmail.com> wrote:\n\n> > ### Availability\n> >\n> > I am expecting to be free from my academic responsibilities by 4th\n> > May. I have no further commitments for the summer and will be able to\n> > provide about 40-50 hours of work per week. I will try porting at\n> > least one file per week, depending on the community feedback and the\n> > pace of the development process.\n> >\n>\n> You have mentioned that you would contribute 40-50 hours per week. That means\n> it would qualify as a \"Large\" size project according to Google's\n> definition [1]. It\n> seems you have mentioned the project size as \"Medium\" while submitting the same\n> in the GSoC website. Have you done this intentionally considering any planned or\n> foreseen unavailability? If so, kindly clarify the same in your\n> proposal. If not and you do\n> intend to contribute the said amount of time, make sure to adjust the\n> project time in the\n> GSoC portal soon.\n>\n> [1]: https://developers.google.com/open-source/gsoc/faq#how_much_time_does_gsoc_participation_take\n>\n\nHello,\n\nI'm confident that I will be able to dedicate ample time to the\nproject, with the exception of a few days in July-August due to my\ngraduation ceremony\nI'm open to changing it to a large project if it is required.\n\nRegards,\nSanchit Jindal\n"},{"id":"492037","messageId":"5B9638BA-7A10-4FBC-AD9B-7C00ABCD4764@gmail.com","threadId":"61211","inReplyTo":"CAN7Jk_2ZQarqVHVCk6=AoUR3sQTFQrK7dfdETwpJvvrdxK6YdQ@mail.gmail.com","subject":"Re: Fwd: [GSOC][Proposal] Move existing tests to a unit testing framework","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2024-04-02T10:19:22Z","receivedAt":"2024-04-02T10:19:29Z","isPatch":false,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"Hi Sanchit,\n\n\nOn 2 April 2024 2:20:02 pm IST, Sanchit Jindal <sanchit1053@gmail.com> wrote:\n>On Tue, 2 Apr 2024 at 11:46, Kaartic Sivaraam\n><kaartic.sivaraam@gmail.com> wrote:\n>\n>I'm confident that I will be able to dedicate ample time to the\n>project, with the exception of a few days in July-August due to my\n>graduation ceremony\n>I'm open to changing it to a large project if it is required.\n>\n\nSure. Kindly change the same in the GSoC portal as soon as possible.\n\nBest,\nSivaraam\n\nSent from my Android device with K-9 Mail. Please excuse my brevity.\n"}]}