On 06/01/13 20:35, 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?
Thank you a lot for this =) I'll answer quickly now, better answer once I'm done with dinner. > Questions > --------- > - 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. Mostly because we have a bunch of users keeping using it for a long time. > - 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!". Nobody is against CC stable and it is usually suggested in review if something not considered for stable actually should. Regarding using more our lovely bugzilla, I guess everybody agrees we should consider it a bit more. > - 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 for release 9 already ^^; > - 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/. We should try to avoid that, indeed. > 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. In my eyes the only two items lacking that you highlighted nicely are: - use more bugzilla to track bugs - make more evident the release window - figure if we want to start an open branch with the beta or the release it is nearly cosmetic IMHO but help the previous point. lu _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
