On Thu, Jan 23, 2025 at 7:57 AM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
>
> (Resent because sending to both -hackers and -www gets emails put in
> the moderation queue, and I don't want to introduce that delay to all
> replies. If you received the previous version because you're in the CC
> please only reply to this one)
>
> # Background
>
> As some of you might have noticed I've been trying to breathe some
> more life into development on the commitfest app[1], both by
> contributing myself but also by encouraging contributions of others.
> Basically I'd like to become one of the maintainers of the commitfest
> app project. The process to get there has been much more of a struggle
> than I'd hoped...
>
> So far I've been sending patches privately to Magnus (who is currently
> the only maintainer afaik). Sadly, Magnus usually has a lot on his
> plate so he often takes a while to respond. This has made the
> turn-around on getting my patches deployed pretty long (even for minor
> patches).
>
> I requested Magnus to give me commit access to the pgcommitfest repo
> so that I could deploy improvements without having to wait for his
> reviews. He didn't think that was a good idea. It turns out we
> fundamentally disagree on what's acceptable way to deploy:
>
> Magnus wants reviews before deployment to be required, in an effort to
> get as close-to-perfect commits as possible. I, on the other hand,
> think that the benefit of close-to-perfect commits is not worth the
> delays in deploying that those reviews currently introduce. I'd rather
> deploy code more often to get feedback from users, and make quick
> improvements/fixes based on that feedback. (this "deploy early, fix
> quickly" approach is also what's being done for cfbot repo and I
> haven't heard any complaints about it)
>
> After some private emails back-and-forth, one thing that we both do
> agree on is that it would be good to move both development and
> discussion of new features into the open. So I thought it would be
> good to also discuss in the open, what exactly that should look like.
>
> # Proposal for new process
>
> I think the following set of guidelines would be a good start:
>
> 1. Development happens on GitHub using Pull Requests (PRs) and Issues
> (see last section for why GitHub). Currently that's on my mirror of
> the repo[2], but that could be moved under the official "postgres"
> GitHub org.
> 2. Chat discussions around development happen on the #commitfest-dev
> channel on the PostgreSQL Hacker Mentoring Discord[3].
> 3. Ideas for new features should be discussed on the pgsql-hackers
> mailinglist to make sure that the users of the commitfest app don't
> hate the idea.
> 4. Small incremental improvements to existing features and bugfixes
> don't need pgsql-hackers involvement.
> 5. Reverts and trivial fixes (typos/forgotten check for None/etc) can
> be deployed without review
> 6. "Big" changes should bake in the staging environment for at least a week.
> 7. If you're deploying a change, you're expected to be reasonably
> available in the next few days after to resolve issues (by reverting
> or hotfixing).
> 8. Feedback/complaints about newly deployed changes can be given on
> pgsql-hackers (CC-ing the committer & author) or through GitHub
> issues.
I am personally in favor of a more open process like this. The
commitfest app seems like the right piece of infrastructure to try
this with. And we definitely want to spread out the maintenance burden
-- not concentrate it. Now, granted, I know nothing about the CF app
code or deployment process. But it sure seems like a win to remove
bottlenecks and enable well-established contributors like you to
support pieces of our infrastructure. Even if the CF app is down one
day a week, I think that would be fine. It's not like our docs being
down. It's a tool for Postgres developers. I think the bigger problem
would be if it went down for weeks on end and you were MIA and no one
knew how to fix your code. But, I somehow don't think that will
happen. I think it is more important to our community that we enable
more people to support development than it is that every tool we have
is perfectly stable.
- Melanie
