Maybe we can start out by adding some basic CI tests on the mirror repository to sort of 'dry run' the new process?
I'll be happy to submit a PR with some basic tests on the repository.
Regards,
Akshat Jaimini
On Thu, Jan 23, 2025 at 6:48 PM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
<copy pasting Jacob Brazeal's full response to the original version of this email here, to keep the discussion in one thread>
On Thu, 23 Jan 2025 at 01:25, Jacob Brazeal <jacob.brazeal@gmail.com> wrote: >> >> 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.
Yeah, some automated tests would be great.
>> "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.
Yeah, that's a great question. My suggestion would be to have the prod branch simply be a delayed version of the staging branch. So basically the flow for normal changes would be: 1. Create a PR 2. Get reviews and address those 3. Get approval. 4. Change gets merged to the staging branch (using a squash commit or rebase) 5. Staging branch gets deployed to staging server 6. Wait a week if the PR was "Big" 7. Staging branch gets merged into prod branch using a fast-forward-only merge 8. Prod branch gets deployed to prod server
Any problems found on staging would be solved by additional commits/PRs, not by amending commits+force-pushes. That way new contributions can always be based on the staging branch. A benefit of this is that contributors will then automatically do some additional local testing of changes that are on staging, but not yet deployed to prod.
