Re: 3.26 retrospective

[Allan Day <aday gnome org>]

Andre Klapper <ak-47 gmx net> wrote:

...

> 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).

OK.

 

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?

I'm actually already on the release team mailing list. The way I had my mail set up meant that I was missing freeze exception requests; I've changed this now so let's see what happens.

 

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.)

Following the r-t list should be enough to allow issues to be flagged - it's not like every exception should require design approval. That said, I'm personally not entirely sure how to resolve the conflict between the need for interesting features and the impact on quality that we sometimes get. It's really hard to know where the bar should be set.

I realise now that my original mail was perhaps a little too broad, so here's a shorter, more actionable list of steps:

• Elaborate the wiki pages to make it clearer when UI freeze breaks are less likely to be accepted.
  
• Set up a public calendar on cloud.gnome.org that contains the release schedule. Publicise the calendar and encourage non-developers to use it.
• Add two UI review dates to the schedule, one week before and after the UI freeze.
• Commit to making sure that there are bootable VM images available for 3.28.
  
• Investigate ways of bulk installing nightly apps.
• Investigate BuildStream as way to make JHBuild more reliable.

Allan