Comments below. On Wed, 2017-09-20 at 16:40 +0100, Allan Day wrote: > ... > > > Extend the UI freeze (or create a freeze period for major UI > > > changes) and require that breaks get design approval. > > > > > > > What would extending the freeze accomplish? We already have a long > > UI freeze (five weeks). Wouldn't extending the freeze just make it > > harder to land changes? ... > > > > Why should UI freeze breaks require design approval? I'm not aware > > of any instance of us approving a freeze break that introduced a > > controversial design change. Do you have an example of a freeze > > break that you wish we had not approved? ... > > > > The issue I've identified is large changes landing just before the > freeze. Typically these large changes require subsequent smaller > changes to make them release-ready, which often requires close design > involvement.
I don't know the best solution either but the current 3.27/3.28 schedule extends The Freeze by one week (see my other email). The current 'rules' for Feature and UI freeze approvals is to get two ACKs from r-t and informing gnome-doc-list@ - see https://wiki.gnome.org/ReleasePlanning/Freezes#Feature_Freeze If Design and/or Engagement would like to get head-ups we could either adjust that wiki page to mention mailing lists, or a team member should follow release-team@ and forward/discuss relevant changes? r-t members already sometimes answer "+1 if {docs, translator} team agrees; I could imagine a similar pattern for design team. (Or if really needed a formal approval which would require defining design team members in a position to make decisions.) andre -- Andre Klapper | [email protected] http://blogs.gnome.org/aklapper/ _______________________________________________ [email protected] https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
