Re: New process of getting changes into the commitfest app
От | Akshat Jaimini |
---|---|
Тема | Re: New process of getting changes into the commitfest app |
Дата | |
Msg-id | CAO8Bkb4w8JYT4Fj3tUVastf1gQSM3a9n2JbXzwf-HiG+5j02Ng@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: New process of getting changes into the commitfest app
|
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: