Hi Nicolas,
2014-08-16 17:11 GMT+02:00 Nicolas George <geo...@nsup.org>:
> 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.
I did not want to sell Gerrit over mailing-list discussion because the
work-flow is something which should be chosen by the development team
and not outsiders, but wanted to show that tools can help enforcing
some parts of the work-flow.
On the human problems vs. technical means questions I think we have
different opinions. Technical means are exceptionally great tools for
solving _some_ human problems. If the human problem is being not
satisfied with peers' behavior of not following a specific work-flow a
toll which enforces the work-flow would solve it. Making mistakes is
an other (mostly) human problem and we have lintian for example which
helps pointing them out.
>
> 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.
IMO the trimming/rejecting strategy is not something which would ever
make Libav popular among developers/users and this is how we ended in
the current situation. While Libav's communicated release strategy can
attract integrators and distributions like Debian, FFmpeg attracts
developers/users of software based on Libav/FFmpeg due to more
features.
Sticking to those core strategies the two forks will compete forever
until one of them give up - which I see unlikely to happen voluntarily
- and users will keep complaining about Libav's missing features to
distributions' maintainers where FFmpeg is not packaged.
I think the best way out of this situation would be relaxing the
review requirements on Libav's side and letting not-yet-proven of
FFmpeg features in through an experimental/staging phase. If FFmpeg
devs could collaborate with them this way the two forks could be
converged and finally merged and the combined team could maintain a
lot better media library than the current forks are separately.
Cheers,
Balint
>
> 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
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/cak0odpy-qs8olzaqs3a_pqfeuhutoj8mzsmevrukk86nube...@mail.gmail.com
