Re: 3.26 retrospective

[mcatanzaro gnome org]

On Wed, Sep 20, 2017 at 4:50 AM, Allan Day <aday gnome org> 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? In general, we've been operating under the assumption 
that making freeze breaks easy to obtain will usually result in a 
higher-quality release, so I'm surprised by the request to make it 
harder to get a freeze break.

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? I think it's reasonable to require 
design team approval if you want to add this requirement, but there is 
no design mailing list so designers will have to follow the 
release-team list if we take this route. I'm not sure it will really be 
beneficial, though: I suspect you'll find yourself needing to approve a 
bunch of pretty mundane requests, and adding another point of failure 
will probably not please module maintainers.

> Make it clear at which point UI freeze breaks will no longer be 
> accepted.

Hm, I think it's better to handle these on a case-by-case basis, but in 
general:

* A big new feature that introduces lots of new code is only likely to 
be accepted at the very beginning (the first week or two) of the freeze 
period. This is because features like this are pretty much guaranteed 
to introduce a big crop of new bugs, no matter how carefully-developed.
* Significant, noticeable UI changes are not likely to be accepted 
during the final week.

But we can and should make exceptions when appropriate. E.g. in the top 
bar transparency case, I thought it made sense to revert back to our 
previous behavior, even though the request came in quite late. Or if a 
feature is long-awaited and very important, maybe it makes sense to let 
it slip in later than usual. The entire process is for seeking an 
exception anyway. We also consider how stable a particular module is, 
and its release history. If the module has a track record of rarely 
introducing new bugs (e.g. gedit is always rock-solid) then it's more 
likely to be safe to grant an exception. Or if the module has a track 
record of making regular development releases throughout the release 
cycle, then it has had more people testing it in rawhide and 
GNOME:Factory and is also a better candidate for a freeze exception.

> Give marketing a say in whether UI freeze breaks are accepted. (And 
> find someone other than me to take responsibility for this!)

Is this in reference to the nautilus freeze break request? I don't 
think we want to allow major UI changes late in the cycle just because 
it would make the release notes more interesting. This is the only 
recent case that I remember of a UI freeze break being denied: in 
general, it's quite easy to get a freeze break because you only have to 
convince two release team members. In this case, it was a pretty clear 
"no" IMO because it required lots of new code but was not at all 
urgent: exactly the sort of thing that should be stabilized over the 
course of the next cycle.

The other case that went badly this cycle was the transparency freeze 
break request. I think this was a combination of you taking time off at 
an awkward point right after making the request, leaving nobody to 
ensure it was actually implemented, and possible confusion due to 
Mathias not liking the request and due to me forgetting that Andre had 
given his approval (conditional on docs team's approval, which came 
from Sean). I wrote a mail saying that another approval was required, 
when in fact you already had the two required approvals if we count 
Andre's. But none of the gnome-shell developers actually followed up on 
the request or implemented the change. I think this was mainly a 
coordination issue rather than an actual issue with our process.

> Make sure that JHBuild isn't broken, particularly around release time.

Unfortunately some module maintainers do not use JHBuild, and so do not 
notice if their module is broken. E.g. gnome-shell has been broken for 
ages to the point where there is no way anybody could possibly build it 
(some core-dep is at too low a version, I forget exactly what), and 
I've gotten bored of fixing such hugely obvious problems when module 
maintainers don't. I do make sure that the release modulesets always 
build on my computer for the releases that I make, but those are 
tarball modulesets that are different from what developers use. E.g. in 
the gnome-shell case, there was a dependency branch in the master 
branch of some module, which has not been released yet, so the release 
modulesets are fine.

We do have a technical solution to this: replace JHBuild with 
BuildStream. Tristan has continuous integration for BuildStream already 
working, so such build failures will not go undetected and unfixed 
anymore. Hopefully we will not be using JHBuild anymore at all by the 
end of this release cycle. I wonder how the efforts to switch our 
release infrastructure to BuildStream are progressing.

Michael