[FFmpeg-devel] [RFC] Google Summer of Code 2012
michaelni at gmx.at
Thu Feb 2 19:12:16 CET 2012
On Thu, Feb 02, 2012 at 03:15:56AM -0800, Mashiat Sarker Shakkhar wrote:
> ----- Original Message -----
> > From: Michael Niedermayer <michaelni at gmx.at>
> > To: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>
> > Cc:
> > Sent: Wednesday, February 1, 2012 11:47 PM
> > Subject: Re: [FFmpeg-devel] [RFC] Google Summer of Code 2012
> > On Wed, Feb 01, 2012 at 11:32:06AM +0100, Benjamin Larsson wrote:
> >> >Id like to see the libav vs ffmpeg relation clarified in the document
> >> >the names suggest to the average reader a relation that is different
> >> >from what it actually is.
> >> Either edit it yourself or post how you would like to have it clarified.
> > The page says this:
> > (At this point, you're probably wondering why there are 2 IRC channels and 2
> > mailinglists. Ask your mentor, it'll make for a good first conversation
> > topic.)
> > It should say something like:
> > Libav is a fork of the FFmpeg project. Both projects seperately
> > maintain the various parts of the codebase like libavcodec and
> > libavformat. If you have questions feel free to start a
> > disscussion on an open mailing list like ffmpeg-devel.
> No need for another ML troll-fest. It isn't even relevant for a
> prospective student. Think about the rationale behind participating
> in GSoC together - because we share a significant amount of common
> code between us and any work produced by the student will probably
> benefit both the fork. The page should mention that and only that.
You possibly miss the problem i was trieing to address.
Misrepresenting the relation between FFmpeg and Libav.
problem a-> having the 2 names listed together without
clarification of their relation.
problem b-> suggesting use of private communication and preventing
I fully understand that overdoing correcting this is likely not
interresting to a student and thats also not my intent. But there are
moral (and probably legal) requirements of informing the reader
(student or not) about the relation considering it is very obvious
to the authors that the wording hints toward a different and untrue
I wouldnt want to be sued from a user that gets his system hacked
because he used libav instead of ffmpeg thinking it was something
else than a fork of ffmpeg, and would contain all security fixes ...
> > Also:
> > "Note that the self-selected mentor needs to have considerable standing in
> > the community to be eligible for mentoring. "
> > should be replaced by:
> > Note that the self-selected mentor needs to have sufficient technical
> > knowledge for the task he wishes to mentor, there is no need for him
> > to be a member of the libav/ffmpeg community.
> It is important that the potential mentor has some code contribution to
> either of the project.
no (for ffmpeg and IMO)
> The org-admin has to ensure that the potential
> mentor will be able to see the project through to the end. Yes, he has
> to have sufficient technical knowledge
> - demonstrated by his contribution
> to the code-base.
maybe we misunderstand each other
so let me provide an example.
lets assume walken wants to mentor an hypothetical mpeg2 optimiztaion
task. Walken is the guy behind libmpeg2 which in same cases is faster
than ffmpegs mpeg2 decoder. I would 100% support him as mentor
because no doubt he is qualified for that.
> > And:
> > "Likewise, if you choose to define your own Summer of Code project, some
> > community members of considerable standing need to vouch for your project."
> > should be droped.
> > There is no such politics in FFmpeg.
> It's not politics. There may not be any such incident in FFmpeg / Libav
> SoC history, but there are rumors that people become mentor and then they
> accept themselves as student. This may sound a little paranoiac, but we
> must have safeguard.
yes and no :)
We must have safeguards and we do. The gsoc admin has the
responsibility not to let any fake mentors in. Thats unambigous and
With the statement in the text you have
"community members of considerable standing" sounds like writen by a
fascist and this is politics. Besides who is and is not a
"community members of considerable standing" is up to discussion on its
The second part is "vouch", which at least when translated to my
mother tongue is a inappropriately strong word
> > similarly "work ethics" must be droped. Whatever is meant by it it
> > sounds creepy
> > And last but not least, It should go without saying but if you want
> > FFmpeg and libav have a joint GSOC, the technical discussions must stay
> > on public mailing lists and IRC channels from which no ffmpeg developer
> > is baned. (this is not the case in the current design described on the
> > wiki page).
> Do you propose a seperate FFmpeg / Libav SoC ML and IRC channel? Won't
> be of much help, if my experience from past year is worth anything.
> Students may prefer a quieter communication medium - private IRC or
> email. We can impose a rule like x264 where the student will have to
> be ping-able on IRC 24/7 (not everyone will like it) and / or the
> student may have to send a mandatory WIP patch to either of the ML
> before mid-term evaluation. That way, all developers will be able to
> participate in the evaluation process (although the end decision is
> made by the mentor and in rare cases the lead-admin for the org.)
Iam not really proposing a solution just pointing out that all
developers of both projects must be able to participate in the
discussion, design and review of the work done. The final decission
of course would be the mentors.
Its important as random developers will have good ideas how to improve
the design here and there and its bad to loose that, also more eyes
will spot more bugs earlier.
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel