On Tue, 2010-08-31 at 18:18 +0200, Michal Hlavinka wrote: > On Tuesday, August 31, 2010 17:39:11 Jesse Keating wrote: > > On 8/31/10 6:57 AM, Michal Hlavinka wrote: > > > there's no reason why 1.8 won't be ok after 2-3 weeks in updates-testing > > > > An update that changes behavior for the end user would never be > > acceptable as an update to a stable release. Only severe exceptions > > should be made to this rule, where the time/effort to backport the > > important fixes from a new upstream release are cost prohibitive and too > > complicated to do on our own. > > I don't thing there is so much updates that change behaviour, see firefox, > thunderbird, kopete, .... usually there are only new features with old > functionality intact. What I wrote was not a rule, there is always a lot of > space for maintainer's decission. Things like Firefox, and Thunderbird have large external teams maintaining them who appear to have goals around ensuring a consistent user experience, with testing, and so forth, over and above just getting new features. They even do self-updating on some platforms, etc. I would say they are fantastic examples of packages where you can get away with a lower commitment in favor of updating them more frequently because the upstream is known to have the user experience interest as a top priority over adding new features. But that isn't a given for every single piece of software by any means, especially when it comes to upstream testing. I was saying elsewhere that I think what could work for something like the Server SIG would be a very strong commitment to the crit-path bits, regular cross-team meetings to discuss proposals and pain points, and a very co-ordinated planning effort to change the guts of the system. There is some effort to do that kind of thing already with a different treatment of crit-path updates, but I think it should go further. Then, I suppose it would be ok to agree to have a lesser commitment for some other packages like Firefox, especially where Mozilla (and the packager) is known to be doing a very good job providing consistent experience. Jon. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
