> > 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 <postg...@jeltef.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/ >
