Re: Feature freeze break request for Sushi

[Cosimo Cecchi <cosimo cecchi gmail com>]

On Tue, 2019-08-27 at 14:45 +0300, mcatanzaro gnome org wrote:
> On Tue, Aug 27, 2019 at 12:45 PM, Cosimo Cecchi via release-team <
> release-team gnome org> wrote:
> > The two merge requests ([2] and [3]) have been reviewed by Carlos
> > here
> > at GUADEC and should be ready to go in case the feature freeze
> > break is
> > granted.
>
> [2] looks OK for a freeze break, but [3] seems extensive. Are you
> really confident that the chances of a regression (e.g. introducing a
> new crash related to the signals) are low? I'm not sure the quality
> improvement from this MR outweighs the chance of regression?

I understand that the numbers of lines changed may be a cause of
concern, but I am pretty confident that this has low chance of
introducing regressions, since most of the new code only runs when the
new feature is activated.

Of course there's still a chance something could have slipped in
unnoticed, but since we're not in hard code freeze yet, we should still
have some time to fix issues if they come up in testing before 3.34.0.

> How sad would you be if I suggest deferring this to 3.36? I'm not
> opposed to approving a freeze break if you think it's important, but
> I do see reason to hesitate.

It wouldn't be the end of the world, and I trust the release team's
judgement, but I'm not sure that deferring it would necessarily
translate to higher quality, since the current set of MRs have been
tested with 3.34.

Also since Sushi got a major rewrite this cycle, this feature is a nice
user-visible improvement to showcase together with it.

Thanks,
Cosimo