This story of summer started in a dull grey winter at home. Bored, I started lingering around channels and much like the Alice of Wonderland, stumbled into the wonderful world of . Little did I know, it was gonna be one of the best things that happened to me. Below is a story of bugs, PRs , repos, commits, and some more commits. But it is also a story of curiosity, learning, frustrations (a lot of it), resilience (more than you think) and some amazing amazing people of the community. If I have to sum it up for you, I couldn’t think of a way better than this. So here it goes… IRC FOSS Disclaimer: It was a long journey, hence the long blog. The Story #1: PICARD-851: Correctly update parent items on save I started out slow. Figuring things out. has a nicely organized and pretty in python. Something that I have always admired and what motivated me to contribute to this project. I went through and found something I figured I could fix. It took me a complete day to figure my head around the code. Although there was a time when I felt helpless and was about to lose my patience, I was finally able to find where the logic broke and fix it. It felt amazing making my first contribution to Picard. Picard code-base the tickets #7: PICARD-546,287: Add support for tag removal My first big pull request, where I was actually implementing a feature rather than fixing a bug. The entire pull request took a week to complete including the code reviews. I had to delve and add code across the file and tag handling module of Picard. #120: Return empty metadata instead of empty dictionary It was finally a month since I had started contributing to Picard. One of my biggest motivations to contributing regularly was by our org admin ruaok before the start of GSoC ’15. I wanted to hold myself to the same standard, and so I did: 1 PR a day. I was quickly fixing up as many tickets as I could, making sure I kept my mentor, zas’ hands full with code reviews. Everyday was exciting for me as I would skim through Jira looking for tickets I could fix for the day. I managed to fix over 20 tickets in my first month. this post #228: Add Picard 1.4 release notes It was Valentine’s Day and man oh man was it a memorable day for my code-valentine — Picard. We finally released a major Picard version after more than 2 years and over 1000 commits. I also got featured on the , something that made me feel really proud of all the work I had done so far. This was also the time that I had started to visualize how my project would look like. I started pitching proposals of a v2 for Picard and I got a lot of support for the direction that I wanted to head in. If you want a detailed look into what my final GSoC proposal looked like, . release blog post GSoC it can be seen on the MetaBrainz Community Forum #249: Merge pull request #632 from lalinsky/master A few days, later another surprise awaited me — I finally got push access to the main Picard repo. This was the first pull request I merged. This pull request along with was my first time foraying into the world of cross-platform issues. This I believe is the first OSX related bug I fixed, with help from and his trusty ol’ Mac. After hours of remote sessions on the Mac that luks had setup for me, we were finally able to resolve a that was affecting the OSX build. PR #633 luks nasty bug #279: Update Qt5 port This was around the time that I had started to work according to my proposal. We had already released Picard 1.4.1 to fix day 0 bugs that came with 1.4. The development efforts had started to shift toward Picard 2.0. : porting the entire code base to Qt5. The first major GSoC task was up It took and multiple subsequent patches to finally have Picard up and running on Qt5. Major challenges to this port was the lack of documentation on Apart from the PyQt porting guide, I also had to rely on the and figure out the equivalent python bindings. Lucky for me, the guys over at Riverbank (the people who made the PyQt bindings) have done a wonderful job at keeping the bindings as close to the C++ API as possible. This along with stack-overflow and the wonderfully documented Qt5 code, made the porting job much much easier. a mammoth of a pull-request porting for PyQt5. Qt5 porting guide written for C++ Another challenge that I faced was making sure that the above code passed tests on our CI. Picard uses Travis CI, which uses Ubuntu 14.04 containers to build the code. Unfortunately, 14.04 does not have the PyQt5 package for Py2 and building it from source takes forever. As a result, I had to dockerize the repo and run the tests in Ubuntu 16.04 in docker in a Trusty container over at Travis CI. Talk about code-ception. #280: Replace deprecated __builtin__ Next task on my GSoC checklist was equally big. I had to port all of the code to Python 3. I was targeting Python 3.5 for the port. Of much help to me this time were the Python tools, and . I used them to figure out the pieces of Python version 2 code that had been deprecated and to replace them with equivalent Python 3 code. Major part of the problems I faced here were encoding issues. And believe me, they only get magnified if your app is cross-platform and multilingual. pylint python-modernize Couple the above with PyQt5 behaving for Python 3 compared to Python 2, I had to plow through a lot of encoding/decoding/string/bytes issues. Pile (a Python audio tagging library that Picard depends on) on top of this mess and you have a recipe for an encoding/decoding disaster. slightly differently Mutagen After lots of string/byte fixes and banging my head against the wall this , I finally managed to port Picard to Python 3 with all tests passing. \o/ porting black magic code You can find all the above commits in . this massive PR #382: Update setup script to allow submitting pip packages Next, to weed out further bugs, I wanted as many alpha testers as possible. To make their task easier, I packaged Picard into a pip package and released it on . PyPi #393: PICARD-817: Enable high DPI support for Picard I further tackled the issue of Picard not rendering properly on High-DPI screens. This issue mainly affected our OSX users and with the port to Qt5, it was easy to alleviate. Although not mentioned explicitly in the Qt5 documentation, I was able to find a that helped me successfully implement it. Basically I needed to add up-scaled versions of the icons used by Picard in the Qt resources with a special suffix and Qt took care of the rest. couple of blog posts Since the upscaled version of the icons used by Picard were missing, I ended up myself. This was my first time with tweaking with Inkscape, but I think I managed fine. designing an entirely new icon-set for Picard #404: Add coverage reports for codacy Part of my GSoC project included testing the Picard code extensively. To help me get on with it, I set up on the Picard repository to display coverage and linting issues for all builds. This really helped with reviewing code and keeping contributions to the Picard repo clean and upto the quality that is expected. Coverage reports also allowed us to figure out which key pieces of Picard code was untested and target them to ensure there were as less regressions as possible. Codacy #442: Migrate code to json API My next big challenge was moving the webservice API calls from XML to JSON. Initally it meant refactoring the spaghetti code that was the Picard webservice module. I untangled the code and split it into an easy to add upon and classes. WebService APIHelper Next came the actual porting part. I had to manually figure out the differences in the JSON and XML outputs of all the APIs used by Picard (mainly the and the ). MusicBrainz API AcoustID API This port also helped in figuring out the parts of MB JSON API that were missing or behaving differently from the XML API. Bitmap, our resident MB developer was quick to fix blocking the transition to the JSON API for Picard. Picard switching to the JSON API also served as a good way to test our upcoming MB WebService 2.5, that is supposed to be JSON only. all the issues #485: Add appveyor config for windows tests Testing a cross-platform app means you need to get your hands dirty on all 3 OSes. Primarily a Linux user, I had to blindly write CI configs for Windows and OSX. For Windows testing, I have not yet found a better platform than . It is free for FOSS projects and down-right amazing in terms of queuing and build speeds. AppVeyor I didn’t have any options when it came to OSX builds. Although Travis does provide the functionality, the number of OSX containers available are scarce compared to the number of jobs that get submitted. As a result, I faced long queuing times which made the blindly-writing-configs-and-using-Travis-to-test part very difficult. I managed to do it with a wee bit of patience and the fact the OSX has bash. #500: Add v2 plugin manifest compatibility All was well and I was finally on the last step of my GSoC project. All that remained was tidying up the code, fixing any remaining bugs and switching to a more robust plugin packaging and distribution API. I wrote a CLI tool for the same, which you can find . here Link to all the above commits: 500 Commits of Summer Afterthoughts By some stroke of fate, my total commits to the Picard repository are exactly 500 in number as of this post. I shook my head in disbelief and amazement as I let it sink in. I have come a long, long way. During this entire journey, I have learnt a lot of new things: version control, making cross-platform desktop applications, proper unit-testing, i18n, CI, making CLI tools, designing APIs, documenting and reviewing code and most of all . writing modular, manageable and maintainable code Expectation Reality How it actually looked like Frankly, I would’ve never expected last year that would look so green. I have made over this year to FOSS. My coding skills have taken a giant leap from last year. I would recommend every coder to try and contribute to a large open-source project at least once during their lifetime. It teaches you a lot of things that can frankly never be taught anywhere else, and the entire experience is totally worth it! my GitHub 1200+ contributions GSoC is a marvellous platform to incubate contributors to the open-source world. I want to thank my mentor and my org admin for helping me throughout and making sure I had an amazing GSoC experience, and Google for making this possible. zas (Laurent Monin) ruaok (Robert Kaye) This has been an amazing opportunity for me. The community has been nothing short of wonderful to me and I am looking forward to contributing more to MetaBrainz and exploring other FOSS projects. MetaBrainz Originally published at blog.musicbrainz.org on August 31, 2017.
