Hi Aryan, On Thu, Mar 21, 2024 at 2:21 PM Aryan Gupta <garyan447@xxxxxxxxx> wrote: > On Wed, Mar 20, 2024 at 12:06 PM Christian Couder > <christian.couder@xxxxxxxxx> wrote: > > On Sat, Mar 16, 2024 at 7:58 PM Aryan Gupta <garyan447@xxxxxxxxx> wrote: > > > -- About Me -- > > > ==================== > > > > > > I have been enthusiastic about open source from the very beginning of > > > my journey as a software developer. I’ve contributed to other > > > open-source projects, though still a beginner, I’m generally familiar > > > with the process of contribution. The related experiences are all in > > > the contribution graph on my GitHub profile page [1]. In the ZAP > > > Project[2] community, I’ve made over 50 PRs [3]. I also participated > > > in the Google Summer of Code 2023 with the OWASP Foundation and > > > successfully completed it as well [4]. I have contributed to some > > > other small projects as well on GitHub. > > > > It's interesting to know that you have already participated in a GSoC. > > Is there a single blog post about this or more? > > Here it is: https://www.zaproxy.org/blog/2023-09-11-browser-recorder/ I saw that there is one blog post, but I wanted to ask if there are more blog posts. That's because we ask GSoC contributors to post on their blog at least every 2 weeks and if possible every week. > > > -- Strategies for Handling Backward Compatibility -- > > > --------------------------------------------------------- > > > > > > 1. Before implementing any changes, a good understanding of how > > > git-bisect works and how it is structured is very important. So, I > > > will thoroughly analyze the existing usage patterns of git-bisect and > > > list down all the potential areas of impact. > > > > > > 2. To validate the codebase changes and ensure the stability and the > > > backward compatibility of git-bisect command. I will write unit tests > > > for all the required changes. > > > > Do you mean unit tests using the new unit test framework in C. Could > > you show an example? > > > > Not sure about what is the standard way that git uses for writing unit tests. > Could you tell me a bit about this? I was just asking if you planned to use the new unit test framework in C. The "Move existing tests to a unit testing framework" project that we propose on https://git.github.io/SoC-2024-Ideas/ is about moving some unit tests to this new unit test framework. Please take a look at that project to get more information about this subject. > > > 3. I will also try to create some real scenarios where I will be > > > manually testing the desired behavior. > > > > > > 4. We might also need some regression tests to test some of the > > > functionality which can't be tested using unit tests. > > > > In which test script would you add them? > > I will be writing these in bash and will be adding it in a new test case file > inside the git/t directory or maybe in "git\t\t6030-bisect-porcelain.sh" It's better to always use the Unix notation for paths like "t/t6030-bisect-porcelain.sh" starting at the root of the repo, rather than mixing the Unix and Windows notations and adding "git/" before the root. > file. I will try mocking a scenario where we have the BISECT_* files available > in the .git directory and then run git bisect using the command line and then > check the expected results. The t/*.sh test scripts are the right place for end-to-end tests (sometimes called "black box" tests), but not for unit tests that would test some C functions. Both unit tests and end-to-end tests could be regression tests or performance tests. > > > 4. Adding Tests > > > - Through testing for backward compatibility is very very > > > important so that the changes don’t break the existing changes. > > > > > > 5. Documenting the changes > > > - This might also go side by side if mentors need some weekly > > > documentation of the tasks done. > > > > Tests and documentation should be part of the patches that change the > > behavior. So it doesn't really make sense to list them separately in > > the timeline. > > Okay. Maybe a blog post could be a part of this? We ask GSoC contributors to post weekly on their blog, so except for a final blog post, most of the blogging should be also part of the regular work. Thanks for updating your proposal.
