Hey Christian Thank you for the response. On Tue, Mar 26, 2024 at 11:30 AM Christian Couder <christian.couder@xxxxxxxxx> wrote: > > 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. > Oh okay. No, the org didn't have any such criteria we usually had a google meeting once a week where we discussed everything about the week's progress and the next week's plan. Yes I can surely write a blog every one or two weeks whichever would be comfortable for sure if I contribute to git. > > > > -- 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. > Got it. I read and researched on this and yes I can use the latest unit test framework for writing the unit tests. Also I was thinking of a backup plan. If the community later (after getting the proposal accepted) do not agree with the project idea. I can work on the migration of these tests as well. Since there are so many tests, I think I can work on a few if this happens. Here is an example: #include "test-lib.h" #include "bisect.h" static void test_backward_compatibility(void) { /* * will try to do some bisect operations by * keeping the new way of storing bisect state * files, not sure about the how the code will * look like for now because I haven't gone * through git-bisect much but I will do it * for sure */ } int cmd_main(int argc, const char **argv) { TEST(test_backward_compatibility(), "Test backward compatibility of git-bisect"); return test_done(); } > > > > 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. Okay. > > > 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. > Okay > > > > 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. Okay. > > Thanks for updating your proposal. Thank you Regards Aryan Gupta
