On 3/31/2017 6:42 PM, James Almer wrote: > On 3/31/2017 3:19 PM, Michael Niedermayer wrote: >> On Fri, Mar 31, 2017 at 03:07:15PM +0200, Michael Niedermayer wrote: >>> On Fri, Mar 31, 2017 at 01:31:51PM +0200, Michael Niedermayer wrote: >>>> On Tue, Mar 14, 2017 at 12:29:52PM +0100, Michael Niedermayer wrote: >>>>> Hi all >>>>> >>>>> are there any issues/tickets that block making 3.3 ? >>>>> >>>>> What about the spherical API size_t / uint32_t issue ? >>>>> we can change it before the release but not after it >>>> >>>> Ive finally branched release/3.3 off >>>> feel free to backport anything >>>> we also need release notes and all that stuff >>>> >>>> once we all agree ill make 3.3 from it >>> >>> wm4 and ubitux stated on irc that now is a bad time to release due to >>> the many recent merges >>> >>> so what shall we do ? >>> should we release now (as in a few days) anyway ? >>> >>> should we wait till the merge rate slows down ? (no idea when that will >>> be or in what condition the tree will then be) >>> >> >>> should we make a 3.3 release from 0bab78f7e729a76ea7a8cbec7f1de033c52494e8 >>> that is 3 weeks ago with backports ? >> >> heres 0bab78f7e729a76ea7a8cbec7f1de033c52494e8 with commits backported >> till master of today ommiting merges, anything changing version (cant be >> backported due to conflicting version numbers)
Right, forgot the thing about version bumps. I guess it's always possible to revert the commits that bumped library version in release/3.3 after recutting it at the point i mentioned below. Afaik the only one so far (outside of the post release bump) is one that added two functions to spherical.h, so it should be harmless. >> , most hwaccel stuff >> (as likely related to merges), most cherry picks from libav and >> anything that didnt apply / depended on ommited commits >> https://github.com/michaelni/FFmpeg/tree/alternative-3.3 >> >> fate of course passes >> >> do people prefer this over what is in release/3.3 ? > > IMO, this is not ideal. It will make the release/3.3 branch wildly > different than master (and libav master) at the alleged point where it > branched out from it. > > Now, regarding merges, we're like 10 commits away from the massive > bitstream reader batch, which is more or less the only thing committed > to libav for a whole week. So how about we re-cut from master (should be > a matter of merging master into release/3.3, which will be > straight-forward as nothing has been cherry-picked) once we have reached > that exact point?. > Give Google and Kierank a couple days to make sure h264 fuzzing didn't > find anything outstanding, and go ahead with tagging the release. > > However, if the merges really put the tree in an unstable state, as it's > apparently been argued, then i guess what you suggested above is better > than waiting another month to release 3.3. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
