On Wed, Aug 12, 2020 at 9:52 am, Alexandre Franke <afra...@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
_______________________________________________
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n