On Tue, Aug 11, 2020 at 9:16 PM Michael Catanzaro <mcatanzaro 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?
Agree, I don't think the idea was to change it for this cycle, but it's a good point to put it on the table ;-)
--
Alexandre Franke
GNOME Hacker
_______________________________________________
gnome-i18n mailing list
gnome-i18n gnome org
https://mail.gnome.org/mailman/listinfo/gnome-i18n
