# OSS Work - suggestions

* OSS is "slow", as in slow food! We know you (the agent) has different priorities and pace of development; we always try our best to smooth out the edges for you.
Please, when discussing, keep always it in mind.
The same of course applies for us; we try to always keep in mind that our vision and goals do not necessarly match with yours.
* When opening a PR, please follow the PR skeleton; describe as precisely as possible (without disclosures and without mentioning Sysdig) your use case and why the patch is needed
* When opening an issue, please follow the issue skeleton. It is there for a reason!
* If you spot a bug, please open an issue; slack is not a good place to remember about bugs (NON DEVE PASSARE IL MESSAGGIO: APRI IL TICKET)
* When opening a perf related PRs, please write how it was benchmarked and the results
* We all have very different visions on code style; sometimes, visions do not match. Don't fear to defend your position
* We **cannot** do whatever we want with the project. If a PR is completely out of Falco scope, there is no way we will ever be going to approve it.
The community is our shareholder and we must guarantee that the product vision and falcosecurity code of conduct are always satisfied.
That is why we fight back on PRs without description, or PRs that just have a little with how Falco is imagined by the community.
Nonetheless, we still are able to ensure that both involved parties, ie: Sysdig and the community, can work and live together without much concerns; but please help us helping you
* Nowadays, there is plenty of discussions in each PR, specially if big.
Your job isn't done when you open the PR. Following the PR is actually possibly the hardest part of it.
Please make sure to check out for new comments every now and then, and answer back.
* While privately pinging works, the best option is always to keep all the discussion public, even if it seems slower. It also has the side benefit that one can read full past discussions when git blaming the code
* If you are gonna open a huge PR, please before doing so reach to us. Together, we will try to understand whether it should be splitted, and the quicker path to the merge.
Moreover, it's good for us to know about big features before we wake up to a +1000,-600 PR, because it helps us giving high level priorities for the project.
* Changelog line is important for us, because our release document, at least on Falco, uses them to autogenerate release notes.
Please make sure to write them following conventional commits rules (https://www.conventionalcommits.org/en/v1.0.0/)

## offsite

### Parte 1 -> gestione branching fork

Agent-libs -> repo opensource fork di falcosecurity/libs.

* PR aperte su upstream; al limite pre-mergiano sul fork se hanno fretta -> si intende che manualmente avere una lista di PR che, quando ancora non mergiate in upstream, vengono già mergiate sul fork

T0 -> PR su oss libs da draios
        T1 -> la PR serve a draios -> aprono un "release" branch per la finestra temporanea tra T0 e T3, cioè mentre i due master divergono, e se la mergiano
                T2 -> PR mergiata su oss libs, può anche essere diversa come forma rispetto a quella in T0
                        T3 -> draios si synca con master, killa il vecchio branch di release e stacca un nuovo branch di release per la nuova window
                            T4 -> draios si riprende tutte le PR eventualemnte ancora aperte sul precedente branch di release, e se le cherrypicka una a una nel nuovo branch

Funziona bene in caso di bug/escalation per draios.

### Parte 2 -> gestione delle feature agent-only

Per le feature, bisogna stabilire quando è utile upstreamarla o tenerla nel fork e basta -> parte ovviamente più difficile, perché spesso una feature closed ha bisogno di aggangi nel codice oss.

In tutto questo serve uno stato di "liste di PR" che interessano a loro, da salvare da qualche parte.
Si sta assumendo che oss libs è la source of truth, perciò tutto ciò che entra da noi, entra anche da loro.

**dal punto di vista tecnico la policy che dobbiamo trovare è che i loro eventuali merge vadano in fast forward**

* L'idea migliore per gestire il tutto è ricreare una nuova API libsinsp (1.0) che inizialmente va in parallelo con libsinsp attuale, di modo che
l'inspector implementi interfacce e sia facilmente estendibile (via interfacce c++ o add_subdirectory cmake) da parte dell'agent
Modern libsinsp?

#### use-case d'esempio: optimizer
* con l'optimizer loro potevano crearsi il loro filtercheck cached (estendendo il nostro filtercheck), e salvarci dentro i field che gli servivano, senza toccare codice oss

#### Altra proposta by Leo:
* fare pezzettino per pezzettino finché non portiamo tutto ad essere estendibile; cioè le feature che ad oggi sono agent-only.

**Case study: analyzer -> perché è molto complesso e quindi ci permette di capire qual è l'effort delle due strade**

Probabilmente il case study ci può aiutare a prendere una decisione migliore sul git branching model;
pertanto ha senso prioritizzare il secondo punto.