Kaartic Sivaraam <kaartic.sivaraam@xxxxxxxxx> writes: > On 20/08/21 8:05 pm, Atharva Raykar wrote: >> Hello Git Developers, >> This is my last week with Git under the Google Summer of Code banner. >> This week's update will be different from usual, as I have split it into >> two separate posts. >> These are: >> 1. The Technical Report: https://atharvaraykar.me/gitnotes/final-report >> This is a largely impersonal report that describes the current status >> of my work. >> Mentors: this is what I will be submitting to Google as my final work >> product. > > Thanks for the report! It's well written. Some comments: > >> Portability: Non-POSIX systems like Windows don’t play nice with shell >> script commands like grep, cd and printf, to name a few, and these >> commands have to be reimplemented for the system. There are also >> POSIX to Windows path conversion issues. > > I wonder if that's a valid claim. The shell script version of the > commands use a lot of *nix utilities to achieve their goal. This comes > as a hindrance to run the corresponding commands on other platforms such > as Windows which don't have these utilities. That doesn't mean those > platforms implement those utilities for their platforms. From what > I know,They just use an emulation layer in which the *nix commands would > be available. Using an emulation layer is costly and not an ideal solution. Maybe I didn't phrase it well enough. Maybe doing a s/reimplemented/emulated at a cost/ would fix it? (Welp, unfortunately I cannot edit the GSoC project description which has this same text. That blooper would be set in stone.) >> Miscellaneous > > You could consider mentioning that the first two changes have been merged > to the 'master' and possibly also link to the corresponding commits. Okay. >> Structuring Patches > > Structuring was indeed an overarching theme your work. > > This taught me how effective communication makes software scale—your >> changes should tell a story that’s easy to follow, so that the code >> can easily be picked up by others by a mere examination of its >> commit and list history. > > Good point. > > Speaking about structuring, I must mentioned that the structuring approach > has paid off very well till now. I'm inferring this from the fact that > the reviewers haven't expressed any concerns about patches being too > long-ish to review. Having taken a look at the patches that aren't on > list yet, they seem to be structured well for ease of review too. > So, good job! Yes, the strategy has worked well so far. I would say my only major error was holding onto some of the patches for too long, because I did not still have the right idea for when to send the next series. >> What I learned over the course of this project > > Good to see that you had some good learnings from the project. :-) > >> Do let me know if it is missing anything. > > I don't think you missed anything. There's one thing which might > be worth including in the report, though. You could have a section > called "Organization of the work" or something like that which > gives some details about the branches that contain your work and > clarify which ones are still relevant at this point. This could > help future readers (including you!) to quickly get an idea of > the branches and code in your fork. This is a good idea. I will update that blog post soon. The blog's home used to have that but I did a poor job of keeping that up to date.
