Doc team notifications of freeze breaks

2019-09-06 Thread mcatanzaro

Hi,

Historically, our rules for freezes have required notifying 
gnome-doc-list@ of any freeze breaks. This rule has not always been 
followed (I'm a flagrant violator myself). Since nowadays documentation 
operates on a longer cadence (generally years rather than months), I 
think it really doesn't make sense to have these notifications anymore. 
If there are any recent examples of a documentation change being 
committed within the freeze window in response to a freeze break 
notification, please let me know; otherwise, I don't think this change 
should be controversial.


Also, release team really doesn't need to be involved in string freeze 
breaks (to the extent a string freeze break is not a UI freeze break) 
since the internationalization team is well-qualified to handle these.


This means all freeze break requests can now go to just one place:

* String freeze break requests go to 
* Other freeze break requests go to 

unless you're landing a major UI change with string changes, in which 
case you'll still need separate UI freeze and string freeze break 
approvals.


Hopefully this should make freeze break requests a bit easier.


___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: Doc team notifications of freeze breaks

2019-09-09 Thread Shaun McCance
On Fri, 2019-09-06 at 15:47 -0500, mcatanz...@gnome.org wrote:
> Hi,
> 
> Historically, our rules for freezes have required notifying 
> gnome-doc-list@ of any freeze breaks. This rule has not always been 
> followed (I'm a flagrant violator myself). Since nowadays
> documentation 
> operates on a longer cadence (generally years rather than months), I 
> think it really doesn't make sense to have these notifications
> anymore. 
> If there are any recent examples of a documentation change being 
> committed within the freeze window in response to a freeze break 
> notification, please let me know; otherwise, I don't think this
> change 
> should be controversial.

I think this is a mistake. One of the reasons we have a release cycle
with freezes is to give the documentation team (and others) a chance to
get anything done. If people aren't notified of freeze breaks, then
there is very little point in having the freezes in the first place.

If sending notifications is too much of a burden for maintainers, then
perhaps the release team should notify interested parties. Or maybe we
need to rethink how we handle freeze breaks entirely. Perhaps we could
devise a GitLab-based solution where the right people are automatically
looped in.

--
Shaun


___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n