We are committed to provide major releases yearly and point releases at least on a quarterly basis. We try to maintain at least two major releases at a time, while developing the next one.
Point releases will contain mostly bug fixes and performance improvements. The API and ABI will remain stable and only few features might get added. The focus is to provide a stable foundation. We suggest distributions to provide point releases.
On major releases we expect to have disruptive changes:
In order to make the transition as smooth as possible, the removal of deprecated function can span more than whole release cycle.
Our master branch should be always in an almost stable condition, we provide a quite large regression testing framework and we monitor its reports to make sure everything is working as expected on a wide variety of systems. We advise to check FATE before distributing a snapshot or run it yourself.
If you are not represented yet in FATE and you have the resources to provide reports please contact us.
We strive to implement and provide useful and innovative features in a timely fashion, provide stable releases and interact to the best of our abilities with our downstream distributors and end users. Supporting a large variety of systems and compilers is an ongoing effort, as witnessed by our FATE continuous integration system. Thanks to the dedication and effort of many developers even difficult targets such as the Microsoft Visual C compiler are supported through a series of toolchain wrappers.
We are not afraid to overhaul radically our code in order to provide a better foundation for future works and we prefer to spend effort to get clean code right instead of piling up special cases and heuristics.
We are patient enough to track bugs and corner cases until they are completely solved
With the help of our users we try to improve the experience of using both the libraries and the tools
We try to focus both on real world issues as well on experiments that might lead to new interesting outcomes.
We are happy to learn that the now arisen competition has finally lead FFmpeg to merge important and long requested features such as frame based multi-threaded decoding based on ffmpeg-mt, something the project leader strongly refused to merge during our attempts to reconcile with him.
We started with a small number of committers for practical reasons. One bad example we had in mind was the experience with the MythTV project where inexperienced git users made a lot of beginner errors after the switch. The likely consequence is that the project will switch back to Subversion.
The list of committers was chosen for multiple reasons. One is available time, the committers must do a lot of patch monkeying and should be able to ensure that the patch queue does not slow down development. Another is git experience, we wish to avoid mistakes and the fate of MythTV.
While the initial committers are trusted and mostly experienced with git, mistakes are inevitable. The point is not that the committers be infallible and incapable of making mistakes but rather that there should be fewer mistakes and when mistakes occur, that they be fixed quickly and effectively.
The list of committers is not fixed and we continue to extend it. New patch monkeys will be chosen by trust and competence through consensus in the current committer team. Committers are trusted not to break the review rules. Being a committer is a duty, not a privilege.
Reviews should be done on a best-effort basis by a person competent in the area touched by the patch. The rule "no commits without review" ensures that another set of qualified eyes looks over code prior to commit. Adopting that policy for all developers - maintainers, committers or first time contributors - puts everybody on equal footing.
If a patch touches a part of Libav that nobody knows well, then review is still done on a best-effort basis. In such a case it is not possible to guarantee the same quality as when expert (in the field) reviewers are available, but general code quality and portability can still be maintained. A review shall then verify that the code does what the author intended and that the change is sensible and beneficial.
We aim to make the lifetime of a patch or a branch minimal. To this end, the amount of nitpicking on patches should be minimized. Documentation typos or small coding style errors can be changed by committers without a new round of review or a new patch submission by the original contributor. Likewise, large patches should not live in separate branches forever. Instead, committers and reviewers should actively reach out to integrate branches into the main tree (i.e. we want to avoid another ffmpeg-mt situation).
Personal conflicts shall be assisted by mediators. When a conflict between two (or more) people arises and threatens to spiral downwards, anybody may ask for a mediator to step in. The role of the mediator is to pull the fighters apart, calm them down, listen to each side and try to restore and aid civil communication towards a resolution.
If reasonable communication fails, a mediator can ask for people to be moderated on the mailing lists so that mails arrive with a delay and combatants have a chance to calm down. Suitable mediator candidates should be calm, level-headed, respected and more or less neutral in the topic at hand. Being uncontroversial as a person and being a good communicator is a plus.
A significant number of active FFmpeg developers feel very unhappy about the way FFmpeg was driven and managed in general and were particularly unhappy with the project leader. Many attempts to resolve and reconcile the issues internally were attempted but unfortunately, all of them failed.
Over the last few years, more and more flames and bickering spread over the ffmpeg-devel mailing list. Important features and fixes were delayed or outright rejected on the grounds of not being perfect. Moreover, project and review rules were applied very inconsistently. Many people were angered and demotivated by this, up to the point of abandoning the project.
In 2010 the situation escalated. A controversial commit resulted in a vote over the leadership position. The result was that the leader would stay, but must follow the same rules as everybody else and amend his behavior. The surrounding flames resulted in one of the most active and experienced developers leaving the project. Multiple developers tried to compose the situation by mediating between the disgruntled and demotivated developers and the project leader.
A few months later we came to the conclusion that the situation had not changed for the better. At first, we decided against forking because most active developers expressed their interest to join it, including the server administrators. We therefore tried to preserve the project as it was. The ensuing flames were expected, but unfortunately a number of people who had not been actively following the discussions protested and sided for the former leader. For a time there were two trees sharing one mailing list, IRC channel with much hostility between them.
Later we have learned that the FFmpeg founder, who owns the domain, still favors the now-demoted project leader. We of course respect his opinion, which convinced us to fork "properly" under the name Libav with its own website, mailing lists, IRC channel and repositories, thus completely separating from the old FFmpeg project. In it, we hope to accomplish what was missing in the former development process -- a friendly environment, free of pointless flames over trivialities, for making THE multimedia library even better than it is now.