Re: fedora mission (was Re: systemd and changes)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



-----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



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux