This is a tiny introduction to Libav, the organization.
The project aims to provide useful tools, written in portable code that is readable, trustworthy and performant.
Libav is an opensource organization focused on developing libraries and tools to decode, manipulate and encode multimedia content.
The project tries to be as non-hierarchical as possible. Every contributor must abide by a well defined set of rules, no matter which role.
If possible, conflicts should be avoided and otherwise resolved.
We are always looking for enthusiastic new contributors and will help you get started. Below you can find a number of possible ways to contribute. Please contact us.
Even if the project is non-hierarchical, it is possible to define specific roles within it. Roles do not really give additional power but additional responsibilities.
Contributing to Libav makes you a Contributor!
Anybody who reviews patches, writes patches, helps triaging bugs, writes documentation, helps people solve their problems, or keeps our infrastructure running is considered a contributor.
It does not matter how little you contribute. Any help is welcome.
Many eyes might not make every bug shallow, but probably a second and a third pair might prevent some silly mistakes.
A reviewer is supposed to read the new patches and prevent mistakes (silly, tiny or huge) to land in the master.
Because of our workflow, spending time reading other people patches is quite common.
People with specific expertise might get nagged to give their opinion more often than others, but everybody might spot something that looks wrong and probably is.
Checking that the bugs are fixed and ask for better reports is important.
Bug wrangling involves making sure reported issues have all the needed information to start fixing the problem and checking if old issues are still valid or had been fixed already.
Nobody can push a patch to the master until it is reviewed, but somebody has to push it once it is.
Committers are the people who push code to the main repository after it has been reviewed.
Being a committer requires you to take newly submitted patches, make sure they work as expected either locally or pushing them through our continuous integration system and possibly fix minor issues like typos.
Patches from a committer go through the normal review process as well.
This infrastructure needs constant maintaining and improving.
Most of comes from people devoting their time and (beside few exceptions) their own hardware, definitely this role requires a huge amount of dedication.
The project strives to provide a pleasant environment for everybody.
Every contributor is considered a member of the team, regardless if they are a newcomer or a founder. Nobody has special rights or prerogatives.
Well defined rules have been adopted since the founding of the project to ensure fairness.
Code of Conduct
A quite simple code of conduct is in place in our project.
It boils down to respecting the other people and being pleasant to deal with.
It is commonly enforced with a friendly warning, followed by the request to leave if the person is unable to behave and, then, eventual removal if anything else fails.
The project has a simple contribution workflow:
- Every patch must be sent to the mailing-list
- Every patch must get a review and an Ok before it lands in the master branch
We have plenty of documentation to make it easy for you to prepare patches.
This post tried to summarize the project and its structure as if the legends surrounding it do not exist and the project is just a clean slate. Shame on me for not having written this blog post 5 years ago.
Past and Present
The Release 12 is in the ABI break window now and soon the release branch will be spun off! After that some of my plans to improve the API will see some initial implementations and hopefully will be available as part of the release 13 (and nihav)
I will discuss
avframe_yield first since Kostya already posted about a better way to handle container formats.