Last week, I got to do something extremely exciting! As I discussed my previous post, I would be the "sheriff", where I am responsible to guide and lead my peers so that we can pave the way to successfully deploy release 2.6 in Telescope .
Duke and I will be "sheriffs" the upcoming week, and I can image that will take a bit of a toll on the projects I push, as I try to support the team and get our goals accomplished. Oh! I should mention - I am so excited to be doing a release. This will be my first time on a more official repository (older me will remember this moment and probably laugh hahaha).
Well, to start off, I was not wrong about the responsibilities taking a toll on my goals for release 2.6! I did not complete as many issues as I wanted to for this week, and it left me falling behind for the release. So my first advice for the role is to take that into consideration.
The second thing I'd like to note is the last bit of my quote, where I will probably laugh. I can look back now and definitely laugh. Not only did I do my first release, I did my second and third. Being sheriff was overwhelming, I wanted to encourage all our contributors and push them in the right direction, ask if they required support when issues went stale, but also handle new high priority issues.
New Issues!
Before we even began the week, we had an issue to tackle! Node-fetch introduced a vulnerability, and unluckily we were using that version. Right away, Duke and I got tasked with handling this fix. I took lead and did the release in Satellite (more below), and then began tackling the issue with Node-Fetch. I thought it would be an easy npm i node-fetch vXXX. I was wrong - I forgot we use pnpm and the process is a little different. I tried to update but nothing was working. What was working was if I did pnpm audit --fix, then I would run pnpm i. However, this was creating an override object in package.json. This is not what I wanted... I read the document on pnpm audit and realized, this is better than what I wanted....
I pushed up my changes, and wrote a quick description of how this worked. I am sure this was new to many of us, as we are just currently working with pnpm in our codebase!
However, we were not done with pnpm... It striked again in Satellite!
We didn't realize our docker containers were still using npm and not pnpm. So when we upgraded Satellite to use pnpm, we added a hook to only allow pnpm. This caused our builds to fail in Telescope. I knew how fast the fix would be, however, I had no time to figure it out, so I created an issue, and assigned it back to the contributor who presented the line of code in the repository. This was not my attempt to point fingers, but the idea of "ownership". That part of the repository is now in their "ownership", and anyone who has questions or needs guidance should go to that individual.
Releases
When I started the release process, I was really lost. Previously, I made a release for my static-site-generator and wrote about it. I will note that my intention for that blog was to help others, and especially myself... This was around the time I began to notice that blogs can be used as notes. This was exactly what I did first thing - pull out my blog. Although I watched how to do a release on Telescope, Satellite was MUCH different. I ended up having to delete the tag I created twice... but nobody will know... unless they read my blog.
Progress on current Issues
As I mentioned, I haven't made much progress on the current issues. I guess I took a step back and decided to prioritize some things, such as the breaking changes in Telescope. I also did some reviews for PRs to get merged in:
Remove all Elastic APM code from Telescope
Add YouTube channel test case for feed discovery service
Modified regex to match user only
Lastly, I followed up and let the group who would install the UI library to let them know Expo PR was landed!
Final Thoughts
Overall, although it feels like I didn't contribute as much as I wanted to in terms of code, I look back and think of the amount of time I spent reviewing PRs, adding labels or updating our documents for the release. I did take a lot of time to read through blogs and look into the repository to understand each individuals interests. I was lucky enough to have Dave provide a skeleton template of areas, and from there I went ahead and filled in the open issues related, and individuals who had an interest in the area on the wiki page for release 2.6 planning. I took charge for the 2.6 planning, and when I was done, I felt as if we had a good amount of issues to tackle, and everyone was taken care of. I wanted to leave that meeting, and have everyone understand how crucial their role is in their contributions, and feel a part of the team. I look forward to seeing how well we push through the next week, as we work to complete the issues under the release. This will give us a better idea of how much we can take on and ship each release.
Top comments (0)