Did I mention I hate pull requests?
You probably landed here because somebody mentioned that I (or perhaps some other like minded person) really hates, despises, loathes, and abhors pull requests.
Pull requests were explicitly designed to create a workflow to handle distrust. They are a gate-keeping mechanism for onboarding code from strangers. So it seems strange to introduce such a mechanism within what should be a close-knit team. Do we really need a process that treats our team members the same way we’d treat strangers?
-- Are Pull Requests Holding Back Your Team?
I'm getting too old for this shit.
-- Danny Glover, Lethal Weapon, 1987
Showing 6331 people
Meet the Core Team
A journey of a thousand miles begins with a single step
Learning from the Best
Thea year was 1999. I was working for IBM at the time. I started a new role as an architect. I was told that there would be no coding. Yeah, that's not happening, I still code to this day.
The web was young. Servlets were new. I had plenty of topics to pick from, and decided to focus on scripting. I worked closely with Sanjiva Weerawarana who at the time was at IBM research. We had Java talking through JNI to things like Windows applications.
But the desktop is not the right place for Java. I went looking for server side scripting. PHP was hot then. In fact, one could say that PHP is still hot now. At the time it, too, had the ability to work directly with windows applications.
I took a look at PHP's source, and compared it to the code I had, and realized I could put them together, subtract the Windows specific portions and have PHP talking to Java in a cross platform way.
PHP had a mailing list, so I posted the outline of a plan, looking for feedback. I'm sure it still is online, but I haven't managed to find it.
The reply I got floored me. Paraphrasing from memory, the reply was:
Here is your CVS account.
I'm pretty sure the reply was from Andi or Zeev, but I recall Rasmus being asked about their policy and whether he was concerned about this resulting in bad code making it into releases, and his response was consistent and concise: "that's what version control systems are for".
Before moving on, a note about CVS. I had never used it before, and I don't know of anybody who still uses it today, but one feature CVS has was the ability to check out a file thereby preventing others from working on that file until you were done. While you would think that would prevent merge conflicts, it actually did the opposite: it encouraged development on long running branches. So instead of continuous and in many cases automatic merges, one had larger and considerably more difficult merges to deal with.
This was replaced in Subversion and later in Git by what amounts to optimistic locks.
This is a consistent theme. Ever process that you have that makes it harder for people to contribute results in more work and less contributions.
About the same time there was an influx of Java to the Apache Software Foundation, and I started contributing to Tomcat. I was dealing with people with no open source experience, and I had been doing it for months (heh) by that point, so I started mentoring projects. Something I did off and on for twenty plus years.
Along the way Commit Then Review (CTR) got added to the Apache Glossary. Optimistic locking taken to the next level. It is not the universal policy of the ASF, but is effectively the default.
Recent Experiences
Fast forward to December of 2022. My current irritant is Rails. They are by no means unique in this matter. Or even the worst (for me, Node.JS has that honor). By now I've contributed to more projects than I can count. GitHub credits me as a Mars 2020 and Artic Code Vault contributor.
On December 19th, DHH added a Dockerfile to Rails. Off the top of my head, I could name many issues. Wouldn't work for Windows Developers. Wouldn't work for API-only applications. Downloading and installing every node module on every build would be intolerable. Hard coding Node version 19 -- or any version different than what the application was using -- would lead to unpleasant surprises. I could go on and on, and for each I could point to an actual customer having a real problem.
And that list will never be complete. I'm still seeing new customers with new problems.
I opened my first pull request on December 22nd. My journey of a thousand miles had begun.
That first pull request was merged on January 9th. At that pace it would take a long time. Admittedly Christmas and New Years were in that gap, but the real problem is that all work was being funnelled through one person, and that person understandably has a large number of other things competing for his attention.
But the fact is that I was available at that time and had a list of unrelated changes that would affect the exact same source files. CTR would have allowed contributions and reviews to happen asynchronously, but that option was not made available to me.
So I spent time researching and documenting. Back in the day we would refer to this approach as "Waterfall". Meanwhile, everything I learned added to my backlog of potential contributions.
For a while things got a bit better. Some pull requests were merged in minutes. But I was still only getting two, maybe three, changes in per day max. And some days, none at all.
January 12th is when I decided it wasn't working for me. The day before I got a comment Would be nice for the final result to look like....
A smarter person would have said something along the lines of "sounds good to me, go for it". Idiot me opened a pull request. It sat for 19 and a half hours.
Before that got merged, I got a request Let’s get the temp fix for COPY in right away.
At one level, adding this my long and growing list was not a problem. Prioritizing it wasn't either.
But two things made me realize that this wasn't going to work for me:
- My cosmetic pull request - the one I produced on request, still hadn't been merged, and this change would have touched the same files.
- If you are going to have an exclusive club and exclude me from being in it, then the merge button is the hand-off point. Tag, you're it. I have no obligation to continue at that point.
Now I'm not suggesting in any way that I've been singled out. There literally have been thousands of contributors to Rails and currently it looks like only about 15 make the cut. The problem isn't me, it is that the bar it too damn high.
Two days later I opened a new repository. I didn't start from scratch, I pulled from places where I had previously solved problems that the Rails team hadn't seen yet.
I was once again in coding heaven. In the first week I got five pull requests and one issue. One added support for SQLServer. Another improved the demo and added:
Tomorrow I plan to migrate from heroku/buildpacks:20 to this and push it to production. The image size decreased from 400 MB to 146.24 MiB. That's Fantastic!
Don't get me wrong - pull requests are great for isolated independent and one time changes. But should anybody emerge that shows an ability and an interest in sustained contributions, I intend to have a low bar and quickly invite them in as collaborators.
Since then I got zero feedback from the Rails team. Just confirmation that I'm not a member of the club (no surprise there) and that DHH got dragged into some other tasks.
Neither of which block me any more.
Future Plans
My plans are to deploy this in production next week, at Fly.io, replacing our current templates with this generator. This undoubtedly will uncover many new bugs and requests for features, and ideally will result in building a community. After all, I not only have a version control system, I have a test suite.
Eventually, Rails 7.1 will come out. If possible I would like this repository to move to the Rails organization where I will continue to be allowed to directly contribute to that one repository. But that's outside of my control. Que sera sera.
Rails is also welcome to harvest from a snapshot at any point. If they do, they will need to find somebody to do that work. I'll continue developing where I feel comfortable and productive.
As a footnote, I was at RailsConf last year, and am hoping to go again this year. Last year I overheard a number of Rails Core members saying that they wanted to make things easier for committers. I personally haven't seen any measurable progress on this front. If those that expressed an interest in working on this are still interested... let's talk.