On Mon, May 03, 2010 at 04:34:13PM +0200, Kevin Kofler wrote: > You make it look as if I was out to break people's systems Actually, I didn't intend to say anything about you. My point was that any increased bureaucracy has not been generated with the intention to reduce the amount of fun that developers have. If developers /do/ feel that their ability to have fun in Fedora has been reduced, I hope that in the long run that that gets more than compensated for by more positive feedback from our users and fewer angry complaints when people's systems break. > * allowing important bugfixes to bypass testing IN SOME CASES (i.e. if they > aren't too risky/non-trivial), in order to get very needed bugfixes (e.g. > regression fixes) out to our users faster and make them suffer LESS, If updates cause regressions in functionality then that indicates that our update testing process failed. The answer to that is to fix the update testing process, not bypass it. > * allowing trivial changes to bypass testing IN SOME CASES (i.e. if they are > important/useful enough) because there's hardly any way they can break > anything, in order to get ultra-low-risk improvements out to our users > faster and make them suffer LESS, There is no change too trivial to not require testing. The software industry is full of examples of obviously correct fixes causing hideous breakage. Most developers get to learn that the hard way at some point, but it's still preferable to put processes in place to protect users from accidents. > * allowing new upstream releases as updates IF AND ONLY IF THEY DON'T BREAK > THINGS (with a very precise definition of "break things" I don't want to > repeat again) and after sufficient regression testing and fixing, bringing > both new features and bugfixes to our users without the breakage of an > unstable distribution such as Rawhide and thus making them suffer LESS. Regardless of your definition, there were several users who felt that the KDE 4.4 update broke things. That's a problem. It makes us look bad. We'd like to avoid those users being unhappy. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
