Re: GConf reverse string freeze breakage approval

[Elijah Newren <newren gmail com>]

On 8/14/05, Christian Rose <menthos gnome org> wrote:

> FWIW, I never ever understood freezes this way. The way I interpreted it
> (and which to the best of my knowledge was never corrected into anything
> else) was that if a freeze was said to begin on a particular date, then
> it was to begin that date, given some appropriate time zone slack of
> course. That is, if a freeze was said to begin on Monday 8th, then we
> would start gradually enforcing the freeze when Monday 8th would no
> longer be, in any time zone of the world.

Right, but who said the freeze started on the 8th?  The schedule has
it listed on the 8th through the 10th.

Your view looks totally reasonable to me.  I'm sure lots of people
share it.  And honestly, I don't care which way is picked, but little
things like this that aren't spelled out seem to keep coming up and
causing annoying snags (besides this, there were multiple people who
mistakenly thought API/ABI freeze applied to desktop modules, there
was confusion over libgnomeprint and whether it broke freezes (due to
being listed as being in one release set but accidentally being
shipped in a different one), no where is it really documented that
maintainers need to make releases even if no code has changed in order
to handle new translations, people often wonder when tarballs are
actually due (when does a maintainer still have time to make them?,
when can I actually begin working on the release and tell maintainers
that they're too late?), what actually constitutes a freeze breakage
(I believe you spelled out the rules for string freeze before but I
doubt everyone knows thems; other freezes are much less clear), and
probably others I'm forgetting at the moment).

> (If release team expected that any GNOME release that would affect
> freezes would not be made in time, then the release team would punt the
> freeze dates accordingly, and announce it.)
> 
> Note that this definition does not include the concept of module
> releases at all; if a module hasn't made a release in time, then bad
> luck for them regarding the freezes, if the freeze is otherwise still in
> effect, IMHO. Most translators do not follow module releases at all, and
> most have not any interest nor any resources to track hundreds of
> software releases to know if the individual modules can be expected to
> have entered string freeze or not.
> String freeze is and should be an all-or-nothing thing to be in any way
> practical. If we can't enforce and expect string freeze across the whole
> module set from a particular date, then we might as well just scrap the
> whole string freeze thing completely, since the trackability (and hence
> usefulness) of it would be hardly worth it anymore. At least not for
> translators.

Note that the timing that Mark and I had in mind would cause no
problems with this; you'd start enforcing the freeze at the end of the
day Wednesday.  Yes, we said modules would enter the freeze when they
made the release, but that's a kind of self-imposed early freeze
entry; doing it that way had the benefit of providing the maintainer
with a solid association for the beginning of the freeze in order to
help them remember it.

But like I said above, I don't care which way becomes official so long
as one does and becomes documented so we don't hit this snag again.

Cheers,
Elijah