Interview With Eric Mann Release Manager PHP 8.3

In this episode, Scott talks with Eric Mann about his experience as one of the PHP 8.3 Release Managers and writing his book PHP Cookbook.

Note: this transcript was transcribed by AI and then edited for clarity.

Scott Keck-Warren:

Hello developers, and welcome to the php[architect] community corner, where we have conversations with members of the web development community. I’m your host, Scott Keck-Warren, and today we’re talking with Eric Mann about being a release manager for PHP 8.3 and his new book PHP Cookbook.

Eric Mann is a well-established cybersecurity, software, and infrastructure engineer, having led multiple teams of various sizes in the private sector. Eric has experience architecting highly-available and resilient SaaS platforms, scalable e-commerce websites, and industry-defining AI/ML operations. In addition to leading technical teams, Eric frequently lectures at events on both scalable engineering and cybersecurity. He also publishes books on programming and secure software design. Eric is a member of both ISACA (Information Systems Audit and Control Association) and OWASP (Open Worldwide Application Security Project) and is a release manager for PHP 8.3.

I wanted to start out today and ask you about your experience as one of the release managers for PHP 8.3.

Eric Mann

Okay. Cool. Yeah. The experience has been fantastic thus far. It’s been a really supportive community, making sure that we get everything taken care of as quickly and as reliably as we can.

One of the things that is really interesting, I did not understand the PHP release process before I started this. I knew we had release managers. I knew we had a release process, but I didn’t really understand what it looked like. So understanding that we cut the release or package the release on one day. On the next day, people will bundle the release for various distributions, and then on the third day we will announce it actually made me feel a lot better just knowing that everybody works from very disparate time zones. And I was really concerned about calendar coordination.

So one of the biggest things I learned was both what the release process looked like, but also just how well suited it is for asynchronous operations and remote work. The fact that I am on the US West Coast and the rest of the release managers are not even in the US, it’s been amazing to coordinate with folks across borders and make sure that we can do things both across borders and across time zones. And as far as how seamless things are from the outside perspective, you can’t tell. Everything is just nice and smooth, and the operation moves forward perfectly well. And I think that’s been amazing and fantastic to learn and see from the inside.

Scott Keck-Warren:

So it kind of sounds like the whole process is set up to be asynchronous.

Eric Mann

It very much is. The way things will typically work is in a release week at some point in time on Tuesday, you will build the release, make sure everything is ready to go, tag the release and then email to tell everybody, hey, the release is ready. Please go ahead and run your builds for Debian and other operating systems, Windows and whatnot.

Sometime on Wednesday, the builders will run their builds and say, hey, here are the builds. They’ll check to see if anything unexpected happened and then let people know where the builds live. And then on Thursday, at some point in time, the release manager will go through and post the announcement for the release, showing where the hash checksums live, where the signatures live, where the binaries live, and all of the compressed artifacts. But all of these happen at different times and everything’s coordinated completely asynchronously via email.

I have now personally managed releases from three separate time zones from Portland, where I live on the West Coast. I’ve gone to the East Coast for work because my office is on the East coast and actually packaged PHP from a hotel room on my laptop, and then most recently was on vacation with my family in Hawaii, and from my hotel room in Hawaii was able to package a release again, exact same process, regardless of where you are, because everything is mediated over email. But it works very well with the asynchronous nature of the work.

Scott Keck-Warren:

So how much time is required of you as one of the release managers?

Eric Mann

It’s actually not that huge of a time demand pulling the release together. The longest thing is compiling PHP, both in threadsafe versus non threadsafe and validating that all of the tests run.

Honestly, I could queue up the release, run the scripts. Maybe 15 minutes later I’m ready to alert the mailing list that the builds are ready. But the process is pretty well streamlined because it’s build the release, sign the release, upload the packages to downloads.php.net, and then alert the release manager mailing list to let everybody know that it’s done. So maybe 15 minutes. The longest was half an hour because I was having network issues.

And then on Thursday, coming back to actually publish the release and announce it, that takes a little bit longer. Not because of the process, but because of the builds in the background. So when you publish an update to the Php.net website or to the QA website, you have to wait up to an hour for the job in the background to actually build the website and make sure that everything is available before you email internals and say, hey everybody, the release is ready to go. You really want to wait for it to be visible on the website before you tell everybody that you released it.

Scott Keck-Warren:

Once you create a release of PHP 8.3, are you then responsible for handling all of the bug requests that come in?

Eric Mann

Not directly. That’s typically managed by the community as a whole, just with the standard release process. So we have when the alphas and the betas went out, we went into a feature freeze. And then there are no new features, no new RFCs in that version, but there can still be bug fixes. And all of those things will go through the typical release cycle on the PHP source GitHub repo, making sure that everybody’s testing and validating and then merging things in as appropriate. Currently, because we’re this far into the release process, things will be merged into the master, the mainline branch to go into PHP 8.4 when its alpha starts up here pretty soon, and then they’re also ported into 8.3 to make sure we get the same bug fixes, but that’s the same feature development bug fix workflow that every version manages. Every version follows all through GitHub.

Scott Keck-Warren:

Can you tell us a little bit about how you were picked to be a release manager?

Eric Mann

Yeah, this all happened through the internals mailing list. So the call for candidates went out. Three of us put our names forward and said, hey, we’re interested in doing this. I’d also put my name forward for PHP 8.2 as well. So folks who can vote typically vote on RFCs as well. We’re able to rank vote their picks for rookie release manager. And then the PHP community uses the single transferable vote mechanism to actually order who the two rookie release managers are going to be.

If you don’t understand single transferable vote, we are an equal company. Because I did not. I thought I lost the election this last time around because I miscalculated. But there are pretty good Wikipedia articles explaining how it works, and some great scripts that some folks have built that help automate counting the votes and tallying the votes. So single transferable vote. Everything happens on the PHP wiki in the public eye to make it really easy and really transparent to understand who’s being selected and when they’re being selected and who is running from release to release.

Scott Keck-Warren:

What made you want to be a release manager for PHP?

Eric Mann

I love PHP. I have not professionally worked in PHP for my day job for about seven years now, but I still continue to use PHP for every hobby project I have. I continue to write for PHP[architect] magazine, the Security Corner article every month. I continue to speak at PHP conferences, lecture on PHP. Recently just published the PHP cookbook through O’Reilly. It’s my favorite language. It’s where I go to whenever I start a new project, and I wanted to give back to the community because really, PHP is what started me in software engineering in the first place, and I felt like I owed it to the community to help give back.

Scott Keck-Warren:

What have you found to be the most interesting part of being a release manager?

Eric Mann

The most interesting thing about this I mentioned I have released from three different time zones. The nifty thing is I’ve all done it from the same machine. So this is kind of my ode to open source. I use an open source Linux machine as my daily driver at home, and I connect it to the internet with a VPN that is also open source. And then I have multiple laptops that can connect back to my home machine.

So even though I built the releases from three different time zones, they were all done by the same machine, open source machine, open source network connections, and has been really fun to be able to leverage all of these tools that years ago were just kind of pie in the sky ideas that I didn’t think we’d ever figured out. But sitting in a hotel roo