On 10/9/2017 8:17 AM, wm4 wrote: > On Sun, 8 Oct 2017 13:53:13 +0200 > Michael Niedermayer <mich...@niedermayer.cc> wrote: > >> On Sat, Oct 07, 2017 at 12:06:23AM +0200, wm4 wrote: >>> On Fri, 6 Oct 2017 16:53:17 +0200 >>> Michael Niedermayer <mich...@niedermayer.cc> wrote: >>> >>>> Hi all >>>> >>>> if there are no objections i will branch release/3.4 in the next days >>>> and make the 3.4 release a few days after that >>>> >>>> If people prefer a specific name, suggest one now, otherwise i will >>>> pick a random one from past suggestions >>>> >>>> If there are features you want in, please push them to >>>> master before the release is branched >>>> if there are bug fixes you want in please ensure they end in >>>> release/3.4 (eiter via master before branching or backport after) >>> >>> I want hardware decoding things in that release (frame pool info, >>> cuvid). I vote the release until this has happened. >> >> Iam not sure what you mean by "I vote the release ..." >> please clarify > > "I vote to delay the release"
Please, don't. It's been months since the last release, and I'm nearing a point in the merges where a release needs to be branched out before i can continue (Technically speaking, I'm at a commit I'd rather not have in 3.4 to being with). The concerns Michael explained about the opaque_ref wrapping in lavc with draw_horiz_band apparently also apply to libav, so maybe talk with the author of the commit you're cherry picking and see if there's a different solution instead? And with Mark about the wrapped_avframe decoder. > >> But i do not think that delaying the release further is what most >> developers want. In case thats what you suggest. >> The release is already several months behind shedule >> >> Releases should be done "early and often", waiting for "in development" >> features will delay a release forever, theres always another feature >> on the horizon that someone wants in. >> >> Of course if the majority wants me to wait with the release, its easy >> to wait for as long as people want me to wait ... >> >> Thanks >> >> [...] >> -- >> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB >> >> Those who are best at talking, realize last or never when they are wrong. > > _______________________________________________ > 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
