Re: New process of getting changes into the commitfest app

>
> 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)

Perhaps we could de-risk this change by adding some automated tests in CI.
I'm happy to help with this effort.

"Big" changes should bake in the staging environment for at least a week.

Would we allow the staging and production branches to diverge very much? I
think the value for automated testing would increase in this case.

On Wed, Jan 22, 2025 at 3:22 PM Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
wrote:

> # 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.
>
> Then there's some open questions that require some more discussion:
>
> a. Do all changes that don't fall under 4 require a review? Or are
> there certain changes that don't need one (e.g. HTML only changes)?
> b. Who can deploy? i.e. can I deploy PRs by other contributors after I
> approve them? An example being [2]? Or is Magnus the only person?
> c. Is there some time after which a PR can be deployed without review,
> even if normally it would require review? i.e. because no-one reviewed
> it in "a reasonable" amount of time
>
> # Call for reviews
>
> Magnus also suggested that I ask more people for a review of my
> existing commits. That seemed like a good idea, so I created a PR that
> contains all the currently not-yet-deployed patches[5]. Note that
> normally these commits would be separate PRs, not one big PR, but
> given this is a new process and they are already deployed to staging
> like this, I just did it this way. I can split them up too though, if
> people prefer that. (just let me know)
>
> You can try these changes out on the staging website[6]. For now that
> requires credentials, but I hope we can make it publicly accessible
> soon. Until that happens just ping me for the credentials.
>
> # Why GitHub?
>
> 1. GitHub has CI and issue/patch tracking included (hosting a
> commitfest app + cfbot instance, just for commitfest app development
> seems like a pain)
> 2. Web developers are generally much more comfortable with GitHub than
> sending patches over email, so this makes the lives of new
> contributors much easier.
> 3. cfbot development is also on GitHub
>
> [1]: https://commitfest.postgresql.org/
> [2]: https://github.com/JelteF/commitfest
> [3]: https://discord.gg/XZy2DXj7Wz
> [4]: https://github.com/JelteF/commitfest/pull/4
> [5]: https://github.com/JelteF/commitfest/pull/7
> [6]: https://commitfest-test.postgresql.org/
>