On Tue, Aug 11, 2020 at 9:16 PM Michael Catanzaro <mcatanz...@gnome.org> wrote: > Hi,
Hi, > I'm fed up with mailman and am trying to decommission the release team > mailing list. That means we need a new procedure for handling freeze > break requests that's not based on email. We've created: > > https://gitlab.gnome.org/Teams/Releng/freeze-breaks 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? > 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). > * 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 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? > 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? -- Alexandre Franke GNOME Hacker _______________________________________________ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
