On Saturday 12 December 2009 00:56:49 Michael Pyne wrote: > > * Fixes to bugs which are easy to verify and have a report in > > bugs.kde.org So if I notice a problem, I have to first report it? > > I'm almost willing to go this route just because it will artificially > inflate my bug-closing numbers. :P
If it's only about cookies, I can send you some and we spare ourselves the policy- wonkiness :-) > > They must not contain > > * API changes > > * New strings > > This will basically be "me too" but there have been string changes in > minor releases when the string was flat-out wrong before. This is > coordinated with the translations teams but not impossible (and nor should > it be). > > I think I've even personally fixed a kdelibs bug that required an API > addition. I'm not sure I'd agree with tilting the "stability" slider all > the way up and forbid these types of fixes for slipstreaming KDE releases > to downstream packagers. I think these situations arise from time to time, but the number of those cases will be rather limited, not frequent enough to warrant writing a policy for every single corner case. What we want to do with this policy is having clarity what point releases mean, not a guaranatee that we'll never, ever make an exception. I think as long as exceptions go through consensus on release-team, it's OK. The policy could just add "the above cases are rubberstamped, if you've anything you'd like to commit to the stable branch which is not granted by the policy, please contact release-team (who will then, for example for string changes pass the ball on to the translators for an OK, or to core-devel for API changes). -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
