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. _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
