-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/31/10 9:40 AM, Thomas Moschny wrote: > 2010/8/31 Jesse Keating <jkeating@xxxxxxxxxxxxxxx>: >> 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. > > An update that does not change behavior for the end user is ... not meaningful. Ok, fair point. "change behavior" is too vague here. I'm trying to draw a difference between fixing a bug (which would change the behavior) and changing things as an "enhancement" or a re-write, or whatever you want to call it. That is if a user is used to interacting with an application in one way that is not somehow taking advantage of a flaw, an update that comes along and changes the way a user has to interact with that software, that is what I wish to avoid. Surprise is not good, one doesn't expect to have to re-discover applications and work flows after applying vendor provided updates for a stable release. > > Any update changes something, otherwise it would not have been issued. > And sometimes it is not at all clear if that change is welcome or not. > A bug fix might be in most cases, but could also mean some work to the > "end user" as well, like removing a workaround. > > We should accept that people have different expectations, and draw > different lines in the trade of getting new bug fixes and new features > vs. coping with breakage and changed behavior. People might even have > different expectations from package to package. If we decide to draw > that line at a fixed point, distribution-wide, we'll lose people, > inevitably. So lets try to come up with ideas how to satisfy both (or > even more than two) needs. Making categories (critical packages vs. > non-critical packages) is a good step in the right direction, as well > as more than one repository. If there are issues the build system or > the packaging tools cannot handle, good, that is a technical problem > and can be solved. We're not here for politics, are we? > > - Thomas I'm not proposing a iron clad rule. I'm proposing a default way of treating our updates and users. Exceptions to the default can be made, and in some cases must be made. I'm arguing though to default on the side of keeping a release consistent and stable throughout the life of the release. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkx9fp4ACgkQ4v2HLvE71NU0YwCguxeBjFNq4+qMk7JsMhwvSGGp MSYAn2RhPBPneRTB4wHztHq3TfbxwK3B =eE3d -----END PGP SIGNATURE----- -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
