[FFmpeg-devel] [VOTE] Equality and leader team
Sun Feb 6 21:56:50 CET 2011
> L'octidi 18 pluvi?se, an CCXIX, Arpi a ?crit.:
> > if they commit to code they know very well, they dont need to send
> > patches to list first, i think.if they are unusure about change,
> > or they have patches for code they dont know in deep then they
> > will send patch first, even if no rules enforcing them to do so.
> > this is why we trust these people enough for giving them write access.
> > at least i did so in mplayer cvs, and it worked.
> > other developers/maintainers still can review tehse commits and
> > revert if they donlt agree, but i dont think it will happen often.
> Even if you are the one who knows this part of the code best by a wide
> margin, sending a patch before applying is IMHO a good thing because:
> - It let knows the others that you are working on something.
when the patch is sent it's already done, not "working on".
i cant see the difference of sending patch to ffmpeg-devel or by commiting
> - Even people who do not know the code very well can make useful
> suggestions ("Why don't you use <some macro> for <this complex formula>?")
> or spot bugs.
they can even do it after the commit was done, and fix/change these instead of
telling the other developer.
> - If someone is working on something else in the same area, it is an
> occasion to discuss your efforts and share the work.
sure but it should happen before the work/patch is ready.
> On the other hand, the policy requiring patches and review should be supple
> enough to allow something like that:
> "I guess I'm the only one who understand that part of the code, so
> I'll approve myself and commit in a few days if there are no
> And with Git, delaying the commit a little is much less a hassle than with
> Nicolas George
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> -----END PGP SIGNATURE-----
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
More information about the ffmpeg-devel