Hi Marton On Wed, Mar 25, 2026 at 11:11:58PM +0100, Marton Balint via ffmpeg-devel wrote: > > > On Thu, 19 Mar 2026, Gyan Doshi via ffmpeg-devel wrote: > > > > > > > On 2026-03-19 06:02 am, Michael Niedermayer via ffmpeg-devel wrote: > > > we have written "3 months" for the milestones about fixing > > > security/fuzzer > > > issues corresponding to the releases: > > > https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2025 > > > > > > and that resulted in March, June and September in the contract. > > > > > > If people want that changed, we can talk with STF about that. > > > But if we do that it should happen now not in june > > > > 3 months seems too short to warrant a new branch. At least it should be > > 4 months for a regular cadence. > > We actually used a 6 month schedule in the past few years for releases. The > more release branches we have, the more work backporting the security fixes > will be, so I am not really convinced it is a good idea to have releases too > often, 6 month seemed like a good compromise. Especially if you intend to > make an effort to maintain some release branches (are we still considering > x.1 branches LTS?) for an extended period.
Are you speaking in general, or specifically about the milestones in the current STF tasks? If this is about release policy in general, then I think that is a separate discussion. Whether we do 1, 2, or 4 releases per year is something the community can decide. If this is about the current STF tasks, then the situation is different. Those milestones were written around a 3 month cadence on the wiki, and that is what the signed contracts were based on. We can perhaps discuss small deadline adjustments if there is a concrete reason, but changing the release plan after signing in a way that reduces the number of releases covered would be problematic. The backporting workload concern is of course real, but that is exactly why these questions should be settled before the contracts are signed, not after. > > As for STF milestones, maybe some more general wording could be used, such > as "fix all reproducible security issues reported until 2026-xx-xx in git > master and the last release branch of ffmpeg". That kind of wording could be discussed for a future STF round. For the current STF, though, these are signed contracts based on the wording the FFmpeg community had on the wiki when it was submitted. They cannot be changed unilaterally afterwards. So yes, for next year, I think suggestions like this make sense. Ideally, they should come together with a concrete plan for who wants to do the corresponding work. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
