This seems like a great idea ! 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 <postg...@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.braz...@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. > > >
