On Sun, Jan 06, 2013 at 02:35:20PM -0500, Derek Buitenhuis 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?
It is infinitely better, thank you. > 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? The problem is getting people interested in releases at all. I took the initiative to do releases again with 0.5 after what felt like an eon and I can tell you that the enthusiasm to join the effort over the years has been ... limited. Getting devs interested in working on branches is even harder. Then you have to get testing for those branches, which nobody runs and see if issues and patches still apply. Remind me what the advantage to slowing down development on master to bug fixing is please, because I don't see any. The problem we had in this cycle was that we lifted the freeze and opened the tree again when we realized that many downstreams had not yet caught up with API changes. We went in and fixed a number of those. When we felt enough built against our beta(s), we freezed again. Next time we'll keep a closer eye on downstreams from the start. > - Why do we have such a high number of concurrent "stable" releases? We maintain the releases that Reinhard needs for Debian and Ubuntu. There is the option of him doing it alone downstream or us doing it together upstream. > Suggestions > ----------- > > "You must be new here." Well, yes :) Me and later more and more Reinhard, now also Anton and Sean have been driving releases. Reinhard and I have been speaking about how to do and experimenting with the process. We've done different releases in different ways to find out what works (well) and what doesn't in the environment that we work in. > - 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. We did have a stabilization window for this release, at least it was the idea. See above about the unfortunate restarted stabilization window. Apparently the announcements were not as clear as they should have been. They will in the future! Diego _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
