L'octidi 28 thermidor, an CCXXII, Bálint Réczey a écrit : > Using Gerrit and "file ownersip" are not mutually exclusive. Gerrit > can be configured to automatically invite the right people for review > based on the changed path. We recently migrated to Gerrit at the > Wireshark project and it helps a lot in coordinating the reviews.
I am afraid this discussion on "Gerrit" or other similar tools is pointless:
this is trying to solve a human problem with technical means: it never
works.
Actually, I believe all this peer-review business to be a red herring. On
the FFmpeg side, most patches except the very simple ones are sent to the
mailing-list for peer-review, even patches by people with commit rights
working on their own code; they do so not because a rule states they have
too but because this is the best thing to achieve good code. On the other
hand, I remember having seen patches somewhat rushed through the mandatory
review on libav-devel and applied when someone else still had remarks; I
have not kept tabs on that though.
The real issue between the mandatory peer-review on the mailing-list is,
IMHO, control of the project orientation. Not "is this patch correct?" but
"do we want this patch?".
If you are involved in the project, it is very obvious that both branches
have rather opposed views on the project orientation: libav has made a point
of trimming "unnecessary" features and rejecting new ones while FFmpeg kept
them and added some.
A few examples:
* Libav removed ffserver, FFmpeg kept it, trying to unbreak it. The commit
message said "appears simpler to write a new replacement from scratch",
but in the meantime, users are left without the feature.
* Libav removed the framerate detection code, FFmpeg built on it to handle
it in filtering too. I do not find them right now, but I have found a few
files that avconv wanted to encode at an insane frame rate while ffmpeg
correctly guessed; and right now, -vf fps does not work alone with very
common formats in avconv.
* Libav removed the keyboard interaction ("Press [q] to stop") while FFmpeg
extended it.
Beyond these obvious cases, FFmpeg has gained quite a few features that, I
am pretty certain of it, would not have been accepted into libav: the concat
demuxer (has been called "hack" on the mailing-lists IIRC), the lavfi
sources made for testing, support for some obscure format through an
external library, subtitles hard-burning, etc.
The most galling in this issue is that there is no clear decision behind
this orientation. The fork's manifesto stated that everyone was equal
amongst equals, with or without commit rights, but the people who do have
the commit rights are few and of a common mind, they can just give the cold
shoulder to proposed changes that do not suit their personal view of the
project.
Considering these differences in policy, I do not believe the fork can be
merged. Speaking as someone who proposed a few of these "unnecessary"
features, because they were fun or immediately useful, I would not like to
work on a project that would reject them by principle. But I can recognize,
for someone who needs "serious professional" software, the need of working
on something driven with a firmer hand.
Having a fork is not inherently bad, and it becomes necessary when people
have different views for the orientation of the projects.
It becomes bad when people not involved in the project start to suffer from
the consequences of the fork. This is what is happening here, for two
reasons:
* distributions adopting one side of the fork for non-technical reasons;
* one side of the fork not caring about compatibility with the other side.
Of course, these reasons are interconnected.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
