On Wed, Aug 20, 2025 at 6:24 PM Kieran Kunhya via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote: > > On Wed, 20 Aug 2025, 11:37 Michael Niedermayer via ffmpeg-devel, < > ffmpeg-devel@ffmpeg.org> wrote: > > > Hi Pierre > > > > On Wed, Aug 20, 2025 at 09:28:26AM -0700, Pierre-Anthony Lemieux via > > ffmpeg-devel wrote: > > > On Wed, Aug 20, 2025 at 9:24 AM Niklas Haas via ffmpeg-devel > > > <ffmpeg-devel@ffmpeg.org> wrote: > > > > > > > > On Tue, 12 Aug 2025 08:32:39 -0700 Pierre-Anthony Lemieux < > > p...@sandflow.com> wrote: > > > > > Quick reminder that the deadline for submitting your proposal is > > > > > quickly approaching. > > > > > > > > > > Also note that the total amount of the proposed projects is below for > > > > > the minimum threshold for STF to consider the application. > > > > > > > > Despite my initial reservations, I decided to also apply with another > > > > continuation of the libswscale project. Just letting you know as a > > heads up > > > > that I will add my proposal to the wiki shortly. > > > > > > > > How much more is currently needed to meet the minimum threshold? > > > > > > @Michael Niedermayer How many of the 100 modules do you realistically > > > expect to complete? > > > > I think the main uncertainilities are > > 1. If teh community preferrs merges or cherry picks, > > If they want cherry picks its 100 patch(sets) passing review, adding > > tests > > where samples are on our server. > > If we do it as a merge, the work is still there but its different > > likely > > less work. > > Code would be merged in one go, then people could still review the > > individual modules afterwards, and I still would have the same effort > > to > > do to add tests and handle reviews. But maybe fewer people will post > > reviews with a merge than with cherry picks > > 2. > > when the work starts, because i intend to submit some patchset to test > > the whole process as soon as i am not busy with other work in ffmpeg > > So we might end up with fewer than 100 if we do some before STF starts > > 3. > > In all this I assume that the review process is fairly smooth and > > requests > > for major changes would be very rare because that would not work with > > the > > number of modules. > > And i assume that either we have testsamples or we dont and so the work > > adding tests is manageable. But the devil is in the details and tests > > can lead to detected bugs if the results are different between archs > > and so on. And then I would have to debug and fix that unknown number > > of > > bugs > > > > So really if everything is smooth i expect all 100 but if issues arise > > it can be less. > > I will know how badly i miscalcuated this only afterwards ;) > > > > thx > > > > Cherry picking Paul's fork is clearly a destructive and hostile act and is > not good use of STF funds.
I recommend that the proposed SOWs be more specific, i.e. list those forks. [ed.: I would definitely avoid forks from folks that have not shown interest in working with ffmpeg, or at least list those forks as super low priority.] > > STF funds are not there to fund your vendetta against Paul and other forks. > > Kieran > > > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
