KDE/kdelibs/kdecore/sonnet

Sebastian Kügler sebas at kde.org
Tue Dec 1 13:30:43 CET 2009


On Tuesday 01 December 2009 01:10:31 David Faure wrote:
> On Tuesday 01 December 2009, Zack Rusin wrote:
> >On Tuesday 01 December 2009, David Faure wrote:
> > > Yep, seems to work now.
> > >
> > > BUT: this code was committed at the worst possible time (*very* close
> > > to beta1 tagging) and without review, breaking the freeze.
> > > And obviously (from your own words) it's impossible to be sure the code
> > > doesn't introduce any regressions. Can you revert it for now and commit
> > > it again a month from now when trunk is open for kde-4.5?
> > > I don't want to think about what will happen if we ship 4.4 with
> > > infinite loops in some languages :/
> >
> > To be honest I'm not sure if that makes much sense. If the code breaks
> > something, then well it breaks something and if you don't have enough
> > tests you most likely have to wait for a beta for it to be tested by
> > general public. So yea, we can revert it and then let it sit and wait for
> > kde-4.5 beta so that it's tested then or we can let it be tested with
> > kde-4.4 beta. The code was broken for years, it just happened to work in
> > enough cases for english, german and other latin languges which meant
> > that no one cared enough about the other few billion people on the planet
> > to fix it, at least now breakage in this breaks all languages equally.
> > Of course at the end of the day it's your call and if it will make you
> >  sleep better at night then sure revert it.
> 
> What the above logic skips over, is the large period of testing between
> "kde 4.5 is open for commits" (a month from now or so) and "kde-4.5-beta1".
> In general, the reason for freezes like the current one, is that code
> committed in the above interval will get also a lot of testing by us (kde
> developers) before it gets to users. But I can see how locale-dependent
>  code is a bit of a special case since we won't test all languages
>  ourselves (I don't even use kde in french myself...), so the code has to
>  get to end users in order to be tested. From a practical point of view I'm
>  ok with letting this in then. But I can also understand if the
>  release-team decides it should be reverted because it didn't play by the
>  rules and sets a bad example.

My understanding is that this code is a "structural bugfix", i.e. not the least 
intrusive but most correct fix to the problem. I believe that this kind of stuff is 
OK at the start of the beta phase. 

Please do keep an eye on bugreports that relate to this change however, so we don't 
regress. And in the future, try to get intrusive bugfixes committed as early as 
possible in the cycle. (I know, being naive about available time and such.)
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9


More information about the release-team mailing list