Re: New procedure for freeze break requests

[Michael Catanzaro <mcatanzaro gnome org>]

On Wed, Aug 12, 2020 at 9:52 am, Alexandre Franke <afranke gnome org> 
wrote:
> I like the idea, but I am concerned. Gitlab has notoriously bad
> notification handling, and people miss things because of it. Aren’t
> you afraid of that, especially with freeze exception requests, which
> are time sensitive?

This is the first I've heard about bad notification handling. What's 
wrong with GitLab notifications?

If developers were having problems with notifications, we would have a 
disaster, since we need to respond quickly to issue reports, merge 
requests, etc.

> >  That should work fine for everything that only requires approval 
> > from
> >  release team: UI freeze, feature freeze, and hard code freeze. (And
> >  docs team can watch the repo if interested.)
>
> Tentative nod. Do note that some of these changes might affect strings
> which are not frozen yet, but the start of The Freeze also marks the
> start of the string change announcement period. Therefore, in those
> cases, developers would still need to tell us about it (which could
> “just” have been a CC before, now it would require a separate 
> email in
> addition to the gitlab issue).

Right. I don't propose to change string change announcement period.

> >   * i18n team could watch this repo's issue tracker for string break
> >  requests and approve them there, alongside other freeze break 
> > requests;
>
> I’m worried about signal to noise ratio here. Watching activity on a
> whole gitlab project when you’re only interested in a subset of if
> does not seem very compelling. Unless there’s a way for i18n team
> members to only watch a label or something similar?

We could create a label for string freeze breaks, and yes you can 
subscribe just to issues tagged with that label. Now, developers who 
report issues are likely going to forget to add that label -- there's 
no way to enforce that -- but release team can fix it up by adding the 
label when we notice it's missing.

That said, the volume of freeze break requests is relatively low. We 
normally get maybe 5-10 per release cycle. So I think it would probably 
be OK to watch all issues. If we go this route, it would be up to i18n 
team to decide which way you prefer to handle it, since release team 
will be watching all the issues regardless.

> >   * We could continue to use email to gnome-i18n@ for string break
> >  requests and just say that release team no longer needs to be 
> > involved
> >  in string freeze breaks
>
> That makes me wonder why the release team was involved at all so far.
> Not that it changes anything for me personally, but there may have
> been a reason, wasn’t there?

I don't think it's important for us to approve string freeze break 
requests. Now if a substantial UI change was landing after freeze, we 
would want to know, but if only tweaks to strings are landing we don't 
care, that's really entirely up to i18n team to approve.

> >  Do you have a preference (or alternative proposal) for how this 
> > would
> >  work?
>
> I may need a bit of time to think this through. All the proposals,
> apart from the first one, make sense to me and I’m not sure what 
> would
> be the best. Making such a decision 10 days before entering the string
> freeze also looks like bad timing, so maybe we should stick to the
> current method for this release and make a decision early in the next
> cycle?

We can delay if you want. I would rather jump in and figure things out 
as we go, so we can shut down the mailing list, but up to you.

Michael