trunk based development

[scenic igloo]

If you're already a contributor to the Linux kernel, you can skip this thread.

I was talking to @slate depot about various development strategies and how his pipeline might evolve. Here are some related resources which might be of interest to others:

Collecting and displaying test results:
https://allurereport.org/docs/how-it-works/

https://allurereport.org/docs/how-it-works-container-file/

Another strategy was trunk based development, TBD where you're making changes to the main branch and testing them before the merge. This approach benefits from having the closely bound to the developer
For historical reasons, TBD often requires the use of less familiar tooling like Zuul-ci: https://youtu.be/aWA8HFxFpos?t=497
and Gerrit code review:
https://vlab-dev.noaa.gov/code-review/Documentation/intro-rockstar.html

One of the potential improvemnets to the pieline could be the export of test results to sqlite files, using https://sqlite-utils.datasette.io/en/stable/

or using the graphql plugin for datasette to query data from sqlite
https://simonwillison.net/2020/Aug/7/datasette-graphql/

[slate depot]

Thanks for this @scenic igloo

[scenic igloo]

and as I mentioned earlier, I'm eager to know if this is useful so that I can calibrate the suggestions. If these are off target or the wrong level of detail, let me know.

[slate depot]

I've been reading up on TBD, is it fair to assume that the challenge with implementing TBD in most engineering teams it that you often have engineers with varying levels of experience so GitFlow tends to be a more sustainable way to maintain consistency in code quality?