Re: 3.26 retrospective

[Andre Klapper <ak-47 gmx net>]

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  |  ak-47 gmx net
http://blogs.gnome.org/aklapper/