Preface ------- "You sir, are WRONG on The Internet!" http://xkcd.com/386/
This is just going to be a small email detailing some ideas and questions that a relative outsider has about Libav's release process. Certainly better than shouting and yelling on IRC, no? Questions --------- "What a silly question, isn't it obvious?" - Why do we branch off of master for the final release? This seemingly demeans the entire point of the beta testing, and, since the release branch is only created off of master for the final release, the .0 release, in essence, ends up being the real beta. Most every other project (or company) in existence will create a release branch for the first beta (or earlier) and have a feature freeze, to prevent new bugs from being introduced. I mean, what's the point of beta testing when the betas do not actually represent the final released product? - Why do we have such a high number of concurrent "stable" releases? The only project that seems to have more is FFmpeg. It increases maintenance (for the people who actually do it!) and fragment adoption and the user base. Not to mention that Libav has precisely no policy for stable releases, so some stable releases no much, much longer than others without security fixes, if the moon is in the right phase. Dropping a few and releasing all stable releases at once seems like a sane idea, to me anyway. Suggestions ----------- "You must be new here." - Actually track bug fixes. Currently there is absolutely no way to track what should be backported to stable releases. From what I understand, Reinhard gets emails from the Ubuntu package maintainer with lists of CVEs, and then also combs through the git history. This is a error-prone method at best. Perhaps Libav could implement a real policy for this. Ignoring the bug tracker and not letting bugs rot would be a start, and so would CCing bug fixes to libav-stable. I've send a patch for update the developer guidelines for the latter already. I realize this will be met with a lot of resistance from some developers, along the lines of "I don't care about stable releases" or "It's not MY job to CC stable!". - Merge windows. This obviously requires that we branch at beta time. A week or two, before the tentative release, send an email to the mailing list which basically says "If a fix needs to go in, or if you want something in, do it now." Ample warning is key. Not everyone reads every IRC log. An announcement a few days before release, or after it has been tagged in git, is not sufficient. - Don't backport features. That demeans the entire point of a stable release, since you are introducing the same feature at a different minor version number, making it impossible for configure scripts or downstream library users to check for a new enough Libav version. Following this, is that you should not have the same minor versions in a release branch, and master, which introduce different things, or mean different things. It'll lead to stuff like this: https://code.google.com/p/ffmpegsource/source/detail?r=738. See also: http://semver.org/. So what now? ------------ Homer: Oh that's it. You insulted my honor! I demand satisfaction. I challenge you to a duel! Moe: A duel? Isn't that a little extreme? Here, here, have a free beer. Homer: Really? But you've never given anyone a free beer. Moe: Yeah, ain't never been slapped with no dueling glove either. So that's about it for this email. Let the flames^Wdiscussion begin! Ideally I hope an actual set of policies can be agreed upon, and put in document form. I am willing to do the boring write-up, if nobody else wants to. Herding cats is hard. - Derek _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
