On Sun, Jan 6, 2013 at 8:35 PM, Derek Buitenhuis <[email protected]> wrote: > 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?
We did so in the past as you suggested. In fact, 0.5, 0.6, and possibly later releases, first branched and then cherry-picked important patches after some period. I guess that this is what you mean with "merge window" (which is BTW a term that us used quite differently on LKML). I agree that this is what we should do again for release 10. > - 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. Dropping older releases will not magically bring more manpower. But you're right, I guess we can (and probably should) officially EOL the 0.6, and possibly the 0.7 branch. > 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. We do have a bugzilla. I always check bugzilla before cutting a release. Please use it. If a bug had been filed for the libavresample on windows, a lot of drama on IRC could have been avoided. > From what I understand, Reinhard gets > emails from the Ubuntu package maintainer with lists of CVEs, and then also > combs through the git history. I am defacto the ubuntu package maintainer :-) What you mean is by the Debian and Ubuntu security Teams. I usually forward such requests to [email protected], where we can discuss such issues. > 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!". More people actively looking at libav-stable for discussing and eventually backporting such commits would indeed help. Having said this, I guess I should draft some patches for our development documentation about "release blocking bugs", and how to CC: libav-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. Yes, I have to admit that this time, I didn't announce my intend to roll the release 9 on the mailing list. I definitely should have and apologize for that. > > - 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/. Noted. > > 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. Thanks! Cheers, Reinhard -- regards, Reinhard _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
