Re: [FFmpeg-devel] [RFC] How to become release maintainer
On 8/5/2019 11:58 AM, Michael Niedermayer wrote: > On Mon, Aug 05, 2019 at 10:47:56AM -0300, James Almer wrote: >> On 8/5/2019 10:35 AM, Reto Kromer wrote: >>> James Almer wrote: >>> >> master nb_commits % 1500 == 0. >>> And if you make the cut as strict as you suggest, you'll surely get broken releases. >>> >>> I fully agree that such an orthodoxy would result in broken >>> releases. >>> >>> Seen this from a user of releases perspective, a good compromise >>> between availability of new features and deployment of a new >>> version would be a few months, such as one release per season. >>> Hope this input is useful for the discussion. >>> >>> Best regards, Reto >> >> That is the current schedule. It used to be one every three months, give >> or take a month, then changed to six months once that stopped being true. >> The issue is that 4.2 is being delayed way too much, fast approaching a >> year now, apparently because Michael (Who handles releases) is dealing >> with a constant influx of new issues reported by fuzzers, most of which >> he considers a security concern. > > with releases every 3 months several people complained that there are > too many releases. Yes. On top of increasing maintenance work (mostly from you) by having more releases that potentially required backported commits in point releases. > > I agree that 4.2 is delayed too much, ill make that release soon, just > wanted to give the latest sec fixes a ~day on the ML for reviews. > > It does seem judging from the unhappyness with a 3months shedule and > the now unhappyness with a almost 9? month that 6 month is the sweet spot. > So ill aim towards maybe 5months in the future and with unexpected delays > we will then achieve a 6 months release cycle. Six months is a sweet spot, yeah. Ideally, we'd bump major once a year to clean structs and remove deprecated API, and only worry about ABI compatibility between two releases. > > About paul doing the releases, i think the work on codecs and filters > and all the surroundings that he is doing currently is more valuable. > > I appologize for the 4.2 release being late Please take my suggestion into consideration. Every fuzzer reported issue can't possibly be considered a blocker. A first point release being made a week or two after the original should be enough to implement fixes for the less important ones and prevent further delays for the release proper. Thanks for your work with the releases. ___ 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".
Re: [FFmpeg-devel] [RFC] How to become release maintainer
On Mon, Aug 05, 2019 at 10:47:56AM -0300, James Almer wrote: > On 8/5/2019 10:35 AM, Reto Kromer wrote: > > James Almer wrote: > > > master nb_commits % 1500 == 0. > > > >> And if you make the cut as strict as you suggest, you'll surely > >> get broken releases. > > > > I fully agree that such an orthodoxy would result in broken > > releases. > > > > Seen this from a user of releases perspective, a good compromise > > between availability of new features and deployment of a new > > version would be a few months, such as one release per season. > > Hope this input is useful for the discussion. > > > > Best regards, Reto > > That is the current schedule. It used to be one every three months, give > or take a month, then changed to six months once that stopped being true. > The issue is that 4.2 is being delayed way too much, fast approaching a > year now, apparently because Michael (Who handles releases) is dealing > with a constant influx of new issues reported by fuzzers, most of which > he considers a security concern. with releases every 3 months several people complained that there are too many releases. I agree that 4.2 is delayed too much, ill make that release soon, just wanted to give the latest sec fixes a ~day on the ML for reviews. It does seem judging from the unhappyness with a 3months shedule and the now unhappyness with a almost 9? month that 6 month is the sweet spot. So ill aim towards maybe 5months in the future and with unexpected delays we will then achieve a 6 months release cycle. About paul doing the releases, i think the work on codecs and filters and all the surroundings that he is doing currently is more valuable. I appologize for the 4.2 release being late Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [RFC] How to become release maintainer
On 05-08-2019 06:48 PM, James Almer wrote: On 8/5/2019 10:13 AM, Gyan wrote: On 05-08-2019 06:05 PM, Paul B Mahol wrote: Hi, Is there some official way how to become release maintainer? Expecially creating new releases once in a while. I'm not happy with current release management in FFmpeg. Yes, release intervals look to be erratic. What would help is a suggested schedule, something like master nb_commits % 1500 == 0. Commit amount means nothing. You could get a whole new decoder in one, or a fix for a single issue split across seven. Across a small number of commits, yes, this would have an impact. Once you go large, the number of consolidated/piecemeal commits has to even out. And if you make the cut as strict as you suggest, you'll surely get broken releases. My suggestion is for a marker, not an exact cut point, which would be pragmatically decided by the release maintainer to avoid partial patchsets or security fixes. Gyan ___ 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".
Re: [FFmpeg-devel] [RFC] How to become release maintainer
On 8/5/2019 10:35 AM, Reto Kromer wrote: > James Almer wrote: > master nb_commits % 1500 == 0. > >> And if you make the cut as strict as you suggest, you'll surely >> get broken releases. > > I fully agree that such an orthodoxy would result in broken > releases. > > Seen this from a user of releases perspective, a good compromise > between availability of new features and deployment of a new > version would be a few months, such as one release per season. > Hope this input is useful for the discussion. > > Best regards, Reto That is the current schedule. It used to be one every three months, give or take a month, then changed to six months once that stopped being true. The issue is that 4.2 is being delayed way too much, fast approaching a year now, apparently because Michael (Who handles releases) is dealing with a constant influx of new issues reported by fuzzers, most of which he considers a security concern. I agree with him that they should be dealt with, but it should be limited to those considered severe and must be addressed immediately (AKA, blocking issues, with proven effects). We have always made a point release about a week or two after the original, with all the required backported fixes included. I don't see why that's apparently no longer being taken into account. Fuzzer reported issues will not stop or slow down, so unless we get laxer with the assigned severity to such issues and leave a bunch for the point releases, 4.2 may not see the light. ___ 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".
Re: [FFmpeg-devel] [RFC] How to become release maintainer
James Almer wrote: >>> master nb_commits % 1500 == 0. >And if you make the cut as strict as you suggest, you'll surely >get broken releases. I fully agree that such an orthodoxy would result in broken releases. Seen this from a user of releases perspective, a good compromise between availability of new features and deployment of a new version would be a few months, such as one release per season. Hope this input is useful for the discussion. Best regards, Reto ___ 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".
Re: [FFmpeg-devel] [RFC] How to become release maintainer
On 8/5/2019 10:13 AM, Gyan wrote: > > > On 05-08-2019 06:05 PM, Paul B Mahol wrote: >> Hi, >> >> Is there some official way how to become release maintainer? >> Expecially creating new releases once in a while. >> I'm not happy with current release management in FFmpeg. > > Yes, release intervals look to be erratic. What would help is a > suggested schedule, something like > > master nb_commits % 1500 == 0. Commit amount means nothing. You could get a whole new decoder in one, or a fix for a single issue split across seven. And if you make the cut as strict as you suggest, you'll surely get broken releases. > > This is self-pacing - rapid/slow development -> rapid/slow release. > Since the marker indication is known in advance, developers can guess by > when their patches should be pushed to make it in a release. The exact > cut point can be relaxed a bit to allow for important backports. > > Gyan > ___ > 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".
Re: [FFmpeg-devel] [RFC] How to become release maintainer
On 05-08-2019 06:05 PM, Paul B Mahol wrote: Hi, Is there some official way how to become release maintainer? Expecially creating new releases once in a while. I'm not happy with current release management in FFmpeg. Yes, release intervals look to be erratic. What would help is a suggested schedule, something like master nb_commits % 1500 == 0. This is self-pacing - rapid/slow development -> rapid/slow release. Since the marker indication is known in advance, developers can guess by when their patches should be pushed to make it in a release. The exact cut point can be relaxed a bit to allow for important backports. Gyan ___ 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] [RFC] How to become release maintainer
Hi, Is there some official way how to become release maintainer? Expecially creating new releases once in a while. I'm not happy with current release management in FFmpeg. ___ 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".
