El mié., 12 ago. 2020 a las 9:53, Alexandre Franke (<afra...@gnome.org>) escribió:
> 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? > 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 >
_______________________________________________ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
