Re: 3.26 retrospective

[Allan Day <aday gnome org>]

Hey Michael,

Thanks for your quick reply. Do bear in mind that these are just ideas; I'm happy to discard any that don't make sense!

<mcatanzaro 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? ...

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'm honestly not sure whether we want these big late changes or not (that's probably a separate discussion). However, one feeling I have is that, if developers are going to drop a big feature, they ought to be aware of what improvements are going to be requested by us designers. This is why I suggested the idea of having a major and a minor UI freeze - the major UI freeze would start 2/3 before the minor one, would only apply to major features, and would require design team approval.

 

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

That's useful information. Maybe it would be useful to advertise the final week as a "we're really frozen" period, or maybe hard code freeze could be elaborated to say "freeze break requests are less likely to be accepted during this period".

 

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

 

Nope.

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

Regarding that particular case, my feeling is that the issue was not so much how the freeze break request was handled, but the fact that it happened so late in the first place. The issue had existed for months; it shouldn't have been a last minute scramble. I think that a UI review around the freeze would have drawn attention to the issue earlier and prompted a more concrete plan for resolving it. I also feel that if it had been flagged and advertised as a release blocker it would have got more priority generally.

 

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.

...

We do have a technical solution to this: replace JHBuild with BuildStream. ...

 

Yes, integrating JHBuild with our CI setup occurred to me as a possibility as well. That could be good.

Thanks,

Allan