PR merge practice

[davinci26]

Hey @ysugimoto

I wanted to see if we could decouple the release process from the pr merge process.

The way we consume Falco is by having an fork of main that has some of our own CI/release timbits. In general we would like to try to have the main branch of our internal repo and this repo be the same but we have some PRs:

• https://github.com/ysugimoto/falco/pull/75
• https://github.com/ysugimoto/falco/pull/74

That have been approved but not yet merged (presumably because you want to cut a release and that takes some time) but I think that we can decouple the two processes.

This would allow us to consume main as it is. Also that would also help with merge conflicts etc.

[ysugimoto]

@davinci26 Could we make a develop branch that is cloned from main branch?

Then we could do the following development process:

1. checkout feature branch from develop
2. create PR to the develop branch, it is able to merge anytime when someone approved
3. to test new features, use binary which is built on develop branch
4. on release, we could merge the develop branch to the main branch and tag it.

What do you think about it?

[davinci26]

I think this works.

I am wondering if it would be easier (less process) if we just merge on main and then tag main:

• every x PRs
• every 3 months
• if someone asks for it with an issue

Basically in that case merge is always "good" quality just binaries are lagging behind by a some time

For us since we are using the latest main if we find a bug on main we are have the incentives to fix it because it blocks our CI system.

[ysugimoto]

I agree with you.

Currently, I merge PRs on my timing, but you can merge them if any contributors approved.

[davinci26]

So for example would you be ok with me merging https://github.com/ysugimoto/falco/pull/89?

[ysugimoto]

Yes, let's merge this!