Re: New process of getting changes into the commitfest app

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 <postgres(at)jeltef(dot)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(dot)brazeal(at)gmail(dot)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.
>
>
>