As you all know, we are now following the GNOME release cycle for WebKitGTK+, see:
http://trac.webkit.org/wiki/WebKitGTKStableReleases That page mentions the UI freeze, but all freezes have been merged into The Freeze in the current cycle, see: http://live.gnome.org/ThreePointThree Theoretically after The Freeze, the API is frozen and modules shouldn't add new API nor change the existing one. In our case that menas, that API additions or changes are not allowed in the stable branch. Sometimes, there's a very good reason to change or add new API after the freeze, so that we can break the freeze. Adding new API at the end of the cycle is always more risky, so we should try to avoid it. Sometimes, patches adding new API are waiting for a review during the whole release cycle, and they get reviewed after the freeze, if the patch is important enough we end up breaking the freeze. To prevent these situations I propose to add the API revision period to the cycle. It could be one month before the freeze. The idea is that, at that point, reviewers make an effort to review all patches with r? that add new API. That way there's one month to land those patches. To identify patches adding new API we could add a new keyword to bugzilla NewAPI or something like that. In GNOME bugzilla we have Target Milestone field. Another possibility is using a wiki page like we do for stable releases. The API revision revision period will be announced in this list to make sure reviewers are aware of it. I know this won't avoid that we'll have to break the freeze, but I think it will prevent some cases, specially the ones when there's a patch waiting for review since the beginning of the release cycle. Opinions? -- Carlos Garcia Campos http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3
signature.asc
Description: This is a digitally signed message part
_______________________________________________ webkit-gtk mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
