wip: docs(proposal): 20231220-features-adoption-and-deprecation.md

[leogr]

What type of PR is this?

/kind design /kind documentation

Any specific area of the project related to this PR?

/area proposals

What this PR does / why we need it:

As discussed among maintainers and based on feedback, the need to balance quick project evolution and avoid frequent changes that can disrupt adopters' workflow has emerged. This proposal aims to find that balance in the long term.

Special notes for your reviewer:

Although apparently well structured, the proposal must be considered as an RFC at the moment. The current goal is to ensure the proposed solution offers a good trade-off and will not introduce any unnecessary burden. Any aspect of the proposal can be changed at this stage.

Tentatively for /milestone 0.37.0

Does this PR introduce a user-facing change?:

NONE

[leogr]

cc @falcosecurity/core-maintainers

[incertum]

@leogr some more feedback

• re "Define the number of previous releases that will receive patches or security updates and the duration of this support": I would be very careful with signing up for LTS as it is a huge overhead. For the foreseeable future I would like us to continue to only support patches for the current stable release
• In the table I would just keep "Status" and "Intended for" and as I said before I am not sure if we will benefit from a "Feature Gate". It may make things too complicated.
• Need formal criteria for each status plus for deciding what can be enabled by default (this would also help to audit some of the current defaults, some defaults may not be optimal atm) -> user-friendliness and performance should be on top of the criteria list
• Proposing to formalize an adopters check list for each release going forward aligning with the "adopter expectations on the operational cost of using Falco" you mentioned
• Since this is just the proposal where will the final doc live, under governance?
• For the next 3 releases we need to communicate that we are introducing more formality and as a result we are going to clean up more than usually. Such as acknowledging that some configs or settings are not working well anymore and are replaced by better options xyz
• Another suggestion is to also set some expectations wrt what areas of the project are more frequntly changing compared to areas or aspects that are more stable. For example, configs change often, but we never remove filter fields or rename them and never changed the minimum supported kernel versions per driver etc.
• We also need a plan for undesired changes ... what if a config is broken and can't be fixed? It happened before.
• One area under "Definitions" may be missing, e.g. "Platform support" which should include the kernel version support matrix, container runtimes etc

[leogr]

• re "Define the number of previous releases that will receive patches or security updates and the duration of this support": I would be very careful with signing up for LTS as it is a huge overhead. For the foreseeable future I would like us to continue to only support patches for the current stable release

That item is indeed a non-goal: https://github.com/falcosecurity/falco/pull/2986/files#diff-e21f0482f5d32d905eb0258a61ddc4c61fd7b581adedd882225dec8758d073b1R15-R17

[leogr]

• Since this is just the proposal where will the final doc live, under governance?

The governance is intended for the overall project, not for components. So, I thought just a .MD in the root of the falco repo and a mirror on the website. wdyt?

[leogr]

• We also need a plan for undesired changes ... what if a config is broken and can't be fixed? It happened before.

Could you provide an example? Thanks!

[incertum]

• Since this is just the proposal where will the final doc live, under governance?

The governance is intended for the overall project, not for components. So, I thought just a .MD in the root of the falco repo and a mirror on the website. wdyt?

Great idea yes!

[incertum]

• We also need a plan for undesired changes ... what if a config is broken and can't be fixed? It happened before.

Could you provide an example? Thanks!

Remember the -d flag just broke and we simply could not fix it, hence we decided to just remove it. I agree it may be less likely to happen again, but if it's not a big deal to add a sentence around this why not?

[leogr]

Remember the -d flag just broke and we simply could not fix it, hence we decided to just remove it. I agree it may be less likely to happen again, but if it's not a big deal to add a sentence around this why not?

I would leave this edge case as a general exception :point_down: so we can decide on a case-by-case basis. wdyt?

Any other exceptions to the rules provided by this policy require a formal core maintainer majority vote.

[incertum]

Hi @leogr I think the most recent WIP commit is great.

Looking back at some of my initial feedback https://github.com/falcosecurity/falco/pull/2986#issuecomment-1867277929 I think that was a lot, maybe too much.

After a fresh look I would now just propose to add one more Area, namely Platform Support Area and outline all things OS, arch, kernel versions, container runtime sockets etc support. WDYT?

[leogr]

/milestone 0.38.0 since this is not a blocker for the current release.

[leogr]

@falcosecurity/falco-maintainers please review :pray:

[incertum]

Bump @falcosecurity/falco-maintainers any additional feedback?

[poiana]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cpanato, FedeDP, incertum, leogr

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• ~~OWNERS~~ [FedeDP,incertum,leogr]

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment