On Mon, Aug 24, 2015 at 4:51 PM, Roger Pack <rogerdpa...@gmail.com> wrote: > On 7/31/15, Michael Niedermayer <mich...@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 > https://lists.libav.org/pipermail/libav-devel/2015-August/thread.html > 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 submission/review) 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). > Cheers! > -roger- > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
