[FFmpeg-devel] FFmpegs future and resigning as leader
gajjanag at mit.edu
Mon Aug 24 23:04:35 CEST 2015
On Mon, Aug 24, 2015 at 4:51 PM, Roger Pack <rogerdpack2 at gmail.com> wrote:
> On 7/31/15, Michael Niedermayer <michael at niedermayer.cc> wrote:
>> Hi all
>> Ive been in FFmepg since 14 years and been the leader since 11 years
>> and i feel that iam not the best person for the leader position.
>> I had hoped for a long time that the fork situation would resolve and
>> both sides somehow merging back into one team. All the Libav developers
>> joining FFmpeg again. But even now as the last distributions are
>> preparing to remove Libav, still theres no hint of that happening.
>> Maybe even the opposite.
>> The community is split and its very difficult to be the leader when
>> one is on one side of this split and the other tries everything to
>> push me out
>> I hope my resignation will make it easier for the teams to find back
>> together and avoid a more complete split which would otherwise be
>> the result sooner or later as the trees diverge and merging all
>> improvments becomes too difficult for me to do.
>> also before my resignation, i offer all maintainers who dont yet have,
>> direct write access as i likely will not comb through the ML anymore
>> or not as frequently to apply patches, please send me your public SSH
>> key if you are de facto maintaining or working on some part of FFmpeg
>> or are listed in MAINTAINERs.
>> If people want to continue merges from libav, someone else will have
>> to do these. Indeed i fully admit the work and pressure caused by
>> the merges is a main reason for my resignation.
> Hey thanks sooo much for your work on FFmpeg over the years. I'll
> admit it's one of the few communities that actually has felt
> maintained (mostly by yourself). I also understand that leading is
> lonely work. It always is unfortunately...
> I guess most of the decision making will be decided in person or
> something like that [?]
> Once there's general concensus around what to do I will follow it,
> please post an announcement or something :)
>> FFmpeg belongs to the FFmpeg developers and the FFmpeg community!
>> will i ever return ? ... i might ..., if theres a nice and friendly
>> environment, no hostile forks or at least none i have to interact with.
>> But i will certainly not return as leader, this is not really a role
>> i ever truly liked, more one i ended up with.
> OK so I take this to mean that even if the general concensus was
> "let's just keep them split, and quit the merges from libav" you would
> still step down at this point? (I guess my real question is "what's
> the major objective? To reunify, or to make things more amenable to
> Michael?" My assumption is that it's to reunify the community?)
> I will also admit my one other concern: that without Michael there
> won't be enough active leadership *total* to "fix all the annoying
> bugs" and everything. I.e. it will just become a worse muck. But if
> the hope is that the guys at libav have enough time/energy to do it
> all then the community as a whole would benefit, agree.
> Glancing randomly at
> It appears that most active on the mailing list is
> Luca Barbato and Anton Khirnov and Martin Storsjö(?)
> though I don't know much about it I'm sure there are others lurking.
> I suppose though if we combined forces between the FFmpeg people
> together with them it might be enough leadership. Or at least easier
> than it is now [?] and definitely less duplication of effort. So
> possibly a net win.
> I'll admit one of the thoughts I had for "recombining" was (cough)
> basically directing new patches to libav, then somebody [michael? not
> as a committer, just contributor] going back through the last 4 years
> of commits and trying to get them committed to libav. Fun fun (not
> really--just a lot of work). And possibly not an option dunno.
>> Especially as somehow "leader" is being interpreted by everyone as
>> "the guy who does all work noone else does, and takes all
>> responsibility noone else wants to take"
>> am i still available for consulting jobs releated to FFmpeg?
>> yes, of course i cant gurantee it for the very distant future but
>> currently yes. And in the very distant future, its a maybe, so just
>> ask if theres something ...
>> what about root, git admin roles, ...?
>> Well iam happy to pass them on to whoever the community chooses and
>> trusts. But please be very carefull who you choose!
>> until someone else is choosen i can continue doing the basic things
>> like security updates and opening git accounts, aka theres no urgency
>> in choosing someone, rather please choose wise than quick.
>> what about GSoC? I agreed to mentor and admin that and i will of
>> course finish that for this summer. I may or may not be available
>> in future FFmpeg GSoCs.
>> If you now think "ohh god what should i do, michael resigned"
>> very simple, FFmpeg is yours, that is everyones. try your best to
>> make FFmpeg be the best.
>> Post patches, review patches, apply patches, discuss code and design.
>> Report bugs, bisect, debug and fix bugs, add features, help users.
>> Do friendly merges, and if you like do hostile merges.
>> Its all up to you now!
>> PS: To push a merge, i think this wasnt documented, you need to
>> add a "Merged-by:" to the commit message, thats the only check, i have
>> no special premissions or anything to push merges.
> I would recommend moving the main repo to github--people understand it
> (and permission issues, etc.) more readibly. But that's just me.
If it comes down to a poll for this, I would strongly vote against it.
My views on this are heavily influenced by that of Torvalds,
who has commented extensively on the matter.
The summary is: Github is a great way of advertising/viewing a project,
but is not good for development.
We already get the advertising/viewing benefit, since we have a mirror set up.
The development benefits are minimal IMHO.
Before starting work on this project, I would have agreed with you.
However, for some odd reason, I find my current workflow (patch
far, far better than the Github issue tracker.
Ironically, I spent more time on figuring out the fork/pull request
semantics on Github
than learning how to submit patches.
> And it depends on what the concensus is for "combining" the forks (for
> instance, will it to be mothball FFmpeg [i.e. only security patches]
> and start doing all new commits to libav [and slowly cherry picking
> old commits from FFmpeg -> libav]? if so then it doesn't matter too
> much what happens to the FFmpeg side of things.
> Anyway happy to see the community moving forward, and many thanks
> again to Michael for herculean efforts over the years. Definitely
> FFmpeg would not be where it is without his work. (Another random
> thought: put an add on the ffmpeg.org website "somebody please employ
> michael full time" to alleviate the stress, but again, it may not be
> about the stress, just the community, which is a separate issue).
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel