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 room after eating breakfast before I met with my coworkers, using an old machine to remote into my work machine at home to push a PHP release through jump boxes all the way to downloads that php.net was. It felt like I was living in the future. It was one of the coolest things I’ve done professionally in quite a while.

Scott Keck-Warren:

It’s always amazing to me how in the modern world we have all these abilities to do these kind of remote management, just with internet access everywhere.

Eric Mann

It helps, especially with commit signing. Throughout the release process, the builds are signed with GPG and the commits on the repositories are signed with GPG. And I keep all of my GPG keys secured by the Secure Enclave. The secure hardware on my machine, my physical machine, which meant my remote laptops did not have access to the same cryptographic keys. So networking in remoting in to my primary dev box in order to push that release out was the only way I could do that, and also show that yes, the signatures are valid and they were done by me.

Scott Keck-Warren:

So you just recently released the PHP Cookbook, and I was curious about your experience writing a book .

Eric Mann

It was definitely quite an experience. It took about a year and a half to pull the entire manuscript together. There was a lot of work that I had to do to pull the material in, and a handful of frustrations as I got some of the more advanced topics.

Php itself is remarkably simple, straightforward, easy to use, and that’s one of the reasons why I love it. Some of the packages that we leverage for some more sophisticated features less so.

The most frustrating thing was talking about asynchronous coding in PHP and building all of my examples using these industry standard asynchronous coding frameworks, only to have the frameworks themselves iterate a major version with breaking changes. Literally the day after I sent my manuscript to the technical reviewers to edit it. So all of my technical reviewers went through all of my code samples and said, none of your code works. None of your code is functional. We don’t understand why. Only for me to go back and see between the time I wrote the chapter and the time they received the chapter for review, a major version released that completely changed the entire API, and I had to go back and scrap two months worth of work on a chapter to completely rebuild it, to meet the new API that this platform had released.

That was incredibly frustrating but great from a usability perspective because the newer versions were much more performant, much more streamlined, much more seamless. I think the changes they made were perfect, but trying to document those changes in effectively a third party dead tree edition of documentation that cannot change as the library iterates. Very difficult, very frustrating and had me beating my head against the wall for a couple of weeks trying to figure out a way through it.

Scott Keck-Warren:

I find the interesting thing about the book structure is that it has this problem, solution, and then discussion structure to it, where you talk about a problem, here’s how to solve it. Then you discuss the solution. And how did you figure out what it is that you wanted to talk about in each one of these little mini-articles.

Eric Mann

I took it from a perspective of, here are things that you might want to try to do.

So around strings, what’s something I might want to do with strings or around streams? What’s something I might want to do with streams in PHP? I then turn it into a problem.

So an example with streams. Specifically, I have two streams. How do I copy data from one stream to the other stream, potentially without ballooning memory, because one of the streams might be more or less infinite. And this is something that you might face if you’re building a very large web application with a very long running connection, and you need to generate a very large data stream that needs to go to the PHP output stream. One way you can do this is just by saying echo and just like printing content to the buffer, but eventually you might exhaust PHP memory. I’ve seen other examples where people try to concatenate a string to try to build a very large document, typically XML or something else where you can’t afford for the server to shut down mid transmission.

And again, you’re exhausting memory by just trying to do this. The alternative is to use things like a temporary file stream, and you can write data to that temporary file stream, build your entire document, your entire XML document or Json document to completion. And then you can read that file again and pipe that directly to the output stream, the output, the web client or API client, whatever is reading from that stream is going to get the full content. You’re not going to exhaust memory because none of this is written into memory, it just passes directly through PHP. But that’s also not something that a lot of people are looking for, because they don’t really understand what is the problem that you’re trying to solve. So taking it from the perspective of what is the problem and then what is the solution? And then walk through not just that full implementation, but potential alternatives, helps really illustrate both the technologies and the fundamentals that are going into the solution, as well as other applications you might have for a similar approach down the road.

Scott Keck-Warren:

Is there anything else you’d like to direct our listeners to before you go?

Eric Mann

I can’t think of anything offhand. No.

Scott Keck-Warren:

Thank you again, Eric, for finding some time with us. I have to say another heartfelt thank you to Eric for all of his time today, and thank you for listening to our podcast. If you’re not already a subscriber, make sure you subscribe with whatever your preferred method is so you can get episodes as soon as they’re released, and maybe share this post with a coworker so they can learn from it as well. This podcast is available both as an audio version on the PHP architect website, and a video version on our YouTube channel. This is Scott Keck-Warren, for the PHP Architect Community Corner. Signing off and reminding you to keep listening, keep coding, and keep reading.

 

 

Links:

Voting Results: https://wiki.php.net/todo/php83
Single Transferable Vote: https://en.wikipedia.org/wiki/Single_transferable_vote
PHP Cookbook: https://www.oreilly.com/library/view/php-cookbook/9781098121310/

 

The post Community Corner: Interview With Eric Mann appeared first on php[architect].