Thread: 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@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.
On Sat, 25 Jan 2025 at 06:29, Akshat Jaimini <akshatjpostgresql@gmail.com> wrote: > I'll be happy to submit a PR with some basic tests on the repository. Sounds good, what basic tests do you have in mind? I have this auto-formatting PR open that also adds some github actions: https://github.com/JelteF/commitfest/pull/1