Presenters
Source
🚀 From Mailing Lists to Pull Requests: Can PostgreSQL Embrace GitHub? 🌐
The PostgreSQL community is a cornerstone of the open-source world, known for its robust database and dedicated contributors. But as the landscape of software development evolves, so too does the question of how best to manage contributions. Should PostgreSQL, traditionally reliant on mailing lists, consider embracing GitHub pull requests? The recent presentation on “From Mailing Lists to Pull Requests: Lessons from EngineX’s Journey” offered some fascinating insights, drawing on the experience of the EngineX project. Let’s dive into what we learned!
EngineX’s Story: A Boost in Contributions 📈
EngineX, a project with close ties to PostgreSQL, decided to experiment with GitHub pull requests. The results? Pretty impressive! They saw a significant increase – a 25-50% jump – in contributions. This wasn’t just from core developers; it was largely fueled by what they termed “drive-by” contributors making smaller, easily mergeable changes.
But the benefits didn’t stop there:
- Smoother Debugging: Downstream projects (those that build on PostgreSQL) found it much easier to report bugs directly through GitHub, drastically streamlining the debugging process.
- Broader Visibility: GitHub’s platform naturally increased discoverability and engagement, attracting potential contributors who might not have previously been involved.
🚧 Navigating the Challenges: It’s Not All Sunshine and Rainbows 🌈
While the initial results were encouraging, the presentation didn’t shy away from the potential pitfalls. Transitioning to a new workflow isn’t always seamless, and the PostgreSQL community has unique considerations:
- The Third-Party Risk: Relying on a platform like GitHub introduces a dependency. The speaker highlighted the cautionary tale of SourceForge to underscore this potential risk.
- Workflow Noise: GitHub’s default view emphasizes open issues, which could overwhelm users and create a sense of unnecessary urgency. Imagine a constant stream of notifications – not ideal!
- Lost Branch History: EngineX, in their workflow, opted to delete branches after merging. This means that the history of changes isn’t preserved in the GitHub repository itself.
- Community Comfort: PostgreSQL contributors deeply value the visibility and accessibility of mailing lists, even for small contributions. Changing this established pattern could face resistance.
- The “Hand-Polished Patch” Tradition: PostgreSQL’s meticulous approach to code review – often referred to as “hand-polished patching” – prioritizes readability and thoroughness. Replicating this level of scrutiny within a GitHub pull request workflow presents a challenge.
💡 Finding the Middle Ground: A Hybrid Approach 🤝
The key takeaway from the presentation wasn’t a call to completely abandon mailing lists. Instead, it advocated for a hybrid approach – a way to leverage the strengths of both systems.
Here are some proposed solutions discussed:
- Automated Integration: Imagine a system that automatically posts updates from GitHub pull requests to the PostgreSQL mailing lists. This ensures that everyone sees the contributions, regardless of their preferred platform.
- Sweeper Bots: These automated bots could periodically clean up and archive older issues on GitHub, reducing the feeling of being overwhelmed by a never-ending list of open tasks.
- Exploring Alternatives (and Why They Didn’t Stick): The idea of community-hosted alternatives to GitHub was previously explored, but ultimately dismissed due to the loss of the benefits associated with a widely adopted platform. It’s about leveraging the network effect!
✨ The Future of PostgreSQL Contributions 👨💻
The presentation wasn’t about forcing a change, but about fostering a conversation. The PostgreSQL community’s strength lies in its collaborative spirit and dedication to quality. By carefully considering the experiences of EngineX and exploring hybrid approaches, the community can potentially unlock new avenues for contribution and innovation, all while preserving the values that make PostgreSQL so special.
What do you think? Should PostgreSQL fully embrace GitHub pull requests, stick with mailing lists, or find a way to blend the two? Let’s discuss in the comments below! ⬇️