KDE/kdebase/runtime/platforms/win

[John Layt]

On Wednesday 30 December 2009 11:23:49 Tom Albers wrote:
> Op Wednesday 30 December 2009 10:10 schreef u:
> > On Wednesday 30 December 2009 04:33:28 Patrick Spendrin wrote:
> > > For this special code I checked all changes myself and as maintainer
> > > I'd say they are ok. They are windows specific anyway... ;-)
> >
> > Yep, this is quite OK. But what about others? (this is a question not to
> > you, but a general one ;))
> >
> > It's really great effort to go and fix this, but my concern is that such
> > changes shouldn't be done a) in pre-release time and b) without an
> > explicit review by maintainers of the code. That's why I'd suspend such
> > changes until 4.4 will be released.
> >
> > I have seen quite some releases when "innocent" pre-release change
> > introduced a grave bug :)
> >
> > Cheers,
> > Dmitry.
> 
> I agree.
> 
> I've said the same thing yesterday on IRC. I think it would be best to
>  prevent 'krazy fixes' after beta2 has been tagged, with the exception of
>  license changes and maybe one or two other checks.
> 
> Anyone objecting if I explicitly add that to the 4.5 schedule?
> 
> Tom Albers
> 

Hi,

First up, my apologies to the Windows guys for breaking their build, I had 
planned to test the compile under Windows and am at a loss as to how I forgot.  
Apologies also for being out of contact for the last two days when I should 
have been available to help sort it out.

I would note in my defence that I have been sticking to only the simplest of 
fixes and avoiding anything that might affect functionality.  What actually 
broke, I'm guessing the includes?

I usually don't bother maintainers with such minor fixes as a) half the code 
doesn't have a maintainer or recent contributor, b) they're so small it's a 
waste of their time, and c) most are not interested in krazy fixes anyway, 
many a submitted krazy patch has been ignored.  If they were interested, then 
they would have fixed them already :-)  The major stuff I leave for them to 
fix themselves, but few do.

I definitely support clearer guidelines in the release schedules as to what 
are acceptable changes, not just for krazy but in general.  Too much is 
undocumented or ambiguous and left for people to pick up by osmosis.  Case in 
point is the current release schedule:

November 25th, 2009: Hard Feature Freeze
"... Only bug fixes are allowed..."

November 25th, 2009: Tag KDE SC 4.4 Beta 1
"... Only urgent fixes, such as those fixing compilation errors, should be 
committed..."

December 16th, 2009: Tag KDE SC 4.4 Beta 2
"... Only urgent fixes, such as those fixing compilation errors, should be 
committed..."

January 5th, 2010: Tag KDE SC 4.4 RC 1
"... Only urgent fixes, such as those fixing compilation errors, should be 
committed..."

Based on those criteria, I would say virtually every commit since Feature 
Freeze breaks the rules :-)  I don't think that's what is intended?

Also under Beta 1 it says:

"The usual beta rules apply as soon as the Beta tarballs have been generated."

But there's no indication what those "usual" rules are, perhaps a link to 
whatever page the rules are on would be useful, not that I can find such a 
page.  A clear definition of what each release milestone means and what rules 
apply under say TechBase/Policies/Release_Lifecycle would be great.  Then the 
Release Schedule page would just be a list of dates with links to the relevant 
section.

I agree a blanket ban on krazy fixes before RC1 would be too extreme.  Fixes 
for incorrect licenses, missing copyright tags, spelling mistakes in comments, 
apidox, etc, should still be OK.  Perhaps something for Beta 2 like 'Krazy 
fixes not affecting code may be applied if approved by 2 reviewers, including 
the maintainer where possible.  Krazy fixes affecting code are not permitted".

Cheers!

John.