[FFmpeg-devel] Maintainership Clarifications

[Pascal Massimino]

On Mon, Mar 14, 2011 at 3:53 AM, Thilo Borgmann <
thilo.borgmann at googlemail.com> wrote:

> Am 14.03.11 11:40, schrieb Ivan Kalvachev:
> > On 3/14/11, Luca Barbato <lu_zero at gentoo.org> wrote:
> >> We apologize that this clarification has been a long time coming. We
> >> felt it necessary to allow the flaming to calm down and we had to
> >> organize our thoughts and ideas, but nonetheless this should have been
> >> posted much earlier.
> >>
> >>
> >> * Intentions of the change
> >>
> >> The intention was not to take away anything nor demotivate people.
> >> However, the intention was to implement some changes in a final form
> >> without having them watered down and filibustered in endless
> discussions.
> >>
> >> We did not start out having all the answers prepared and ready or all
> >> the processes defined. We have a vision and some general ideas, the
> >> details are being developed as we go.
> >>
> >>
> >> * Mission statement
> >>
> >> - Work towards a healthy, encouraging and enjoyable environment for
> >>   developing the FFmpeg code base. This shall be achieved through each
> >>   individual's good behavior and intolerance of bad behavior, mutual
> >>   respect, active and positive reviewing of submissions and other
> >>   policies and processes targeted at conserving this environment.
> >>
> >> - Aim to maintain and continually improve the code quality of FFmpeg.
> >>   Peer review, regression testing and refactoring are some of the means
> >>   to achieve this goal.
> >>
> >> - Transform FFmpeg into a one-stop multimedia solution that fulfils all
> >>   the needs of library users in one single package without the need for
> >>   extra libraries for specific formats or needs. To this end we wish to
> >>   implement native support, instead of external library wrappers, for
> >>   all input formats.
> >>   For output formats we recognize that in some cases external libraries
> >>   will remain better for the foreseeable future and that in these cases
> >>   wrappers are preferable, but where external libraries are low quality
> >>   or unmaintained, we wish to supplant them.
> >>
> >> We hope that the following clarifications along with future policies and
> >> procedures will allow us to progress towards the goal of becoming the be
> >> all and end all of multimedia software while allowing all involved to
> >> enjoy the love of programming in a friendly atmosphere.
> >>
> >>
> >> * Committers
> >>
> >> We started with a small number of committers for practical reasons. One
> >> bad example we had in mind was Janne's 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 want more people to join in
> >> the near future. Reinhard and Justin were already added. 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.
> >>
> >>
> >> * Administrators (AKA "roots")
> >>
> >> Administrators are selected by trust and qualification and experience
> >> originating from previous good admin work. Attila, M?ns and Diego, newly
> >> joined by Janne, who managed our git transition and set up our patchwork
> >> system, currently run the main project server. If more manpower is
> >> required, Luca, who already hosts and runs roundup, and Reinhard are
> >> available as backups.
> >>
> >>
> >> * Review process
> >>
> >> 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 previous 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 FFmpeg 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).
> >>
> >> * Maintainers
> >>
> >> A maintainer is a person experienced and/or knowledgeable in a specific
> >> area, willing to make an effort to address bug reports about the area
> >> and to shepherd outside contributions to the area into FFmpeg.
> >>
> >> Maintainership is not file-based - many areas cover many files or even
> >> all of FFmpeg. Maintainership is not code ownership. The project's code
> >> is owned by all its members. No maintainer should veto changes to
> >> specific files or make decisions without technical reasons just for
> >> being the maintainer.
> >>
> >> FOSS software development is based on copyright law and recognizing
> >> individual contributions to the shared codebase. The revision control
> >> tools in use nowadays even allow tracking attribution and thus
> >> copyrights automatically. Nevertheless FOSS is about setting software
> >> free, this includes giving up a certain amount of control. We must be
> >> humble and encouraging towards those wishing to work on our code base
> >> and willing to allow future developers to change our code and take it
> >> in new directions.
> >>
> >>
> >> * Personal Conflict Resolution
> >>
> >> Conflicts, especially personal ones, have been the bane of the FFmpeg
> >> project for many years. The current way of letting conflicts continue
> >> and continue to escalate creates nothing but downward spirals and
> >> unhappiness.
> >>
> >> Personal conflicts shall be assisted by mediators in the future. 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. Currently, we believe Benjamin, Robert,
> >> Reinhard, and Stefano are good candidates for this job.
> >>
> >>
> >> * Code of Conduct
> >>
> >> In order to foster a friendly and cooperative atmosphere where technical
> >> collaboration can flourish we expect all members of the FFmpeg community
> >> to be
> >>
> >> - courteous, polite and respectful in their treatment of others,
> >> - helpful and constructive in suggestions and criticism,
> >> - stay on topic for the communication medium that is being used,
> >> - be tolerant of differences in opinion and mistakes that inevitably get
> >>   made by everyone.
> >>
> >> Plus, we expect everybody to not
> >>
> >> - flame and troll,
> >> - insult,
> >> - be offtopic or
> >> - disruptive of our communication channels.
> >>
> >> While we hope to keep disciplinary action to a minimum, repeated
> >> violations of this policy will result in offenders getting temporarily
> >> or permanently removed from our communication channels.
> >
> > Too little, too late.
> >
> > I'm sorry, but most of these intentions have already been proven to be
> > false and there are quite many examples of actions taken that
> > contradict them. And I won't even start arguing why some of these
> > intentions are bad idea.
> >
> > IMHO The FFmpeg revolution turned out to be a Bolshevik one. It came
> > with ideals of prosperity and equality, and ends with dictatorship of
> > a self-selected elite, oppression  and slowly growing stagnation.
>
> +1
>

+1

(+ the ballooning bureaucracy. It now takes a lawyer or two to understand
what
you can or can't do here around. sweet. i even have to disable image loading
on my mailer, in case i inadvertently stumble upon copyrighted logo i
couldn't unsee)


> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>