Updates Politics Proposal

[Eric Rostetter]

Quoting Philip Molter <philip at datafoundry.com>:

> I agree with this statement, but as a FL user, I can say that one of the
> problems with FL is that outstanding bugs never get fixed.

Security bugs, and major/critical bugs, get fixed.  Minor bugs do not.

> The policy
> of only applying security patches means that outstanding issues for
> which there were open FC bug reports (and even bug reports with trivial
> patches) never get fixed.

That isn't the policy.  Policy is "we will provide security updates and
critical bug fixes".  The question is whether the bug you want fixed can
be considered either security or critical.
 
> To cite a specific example, there is a bug in the e100 driver that
> causes sporadic timeouts.  This bug has been patched with a trivial (2
> or 3 line change) patch in the latest kernel rev.  This patch doesn't
> change functionality or APIs.  It just fixes a thinko.  The patch has
> already made its way into FC3 through the latest kernel release, but FC2
> users are out of luck because of the security-only policy.  This patch
> is no more burdensome than a security patch, yet it's not accepted
> because it's not a security problem.

You simply need to convince us of the trivial nature of the change, and
that it is a "critical" issue.  If the bug can result in corrupted data,
lost data, or broken network connections, then you could reasonably call
it critical, and FL would be expected to apply the existing patches.
 
> I'm personally in favor of expanding the patch policy to fix trivial
> bugs in addition to security bugs.

Your understanding of the policy is wrong, so please understand the 
policy first before you decide to change it.

I'm not sure we should apply a patch just because it is trivial.  For
example, a cosmetic change wouldn't be appropriate in most cases. But
if the patch is for a critical issue (lost data/connections, program
crashes, etc) then it would be up for consideration, whether or not
it is trivial.

> Trivial bug patches can be open to
> discussion, of course ("I'm sorry, but this patch changes too much
> behavior to be accepted"), but they shouldn't be outright denied simply
> because the issue they fix isn't solely security-related.

Nor should a patch be applied simply because it is trivial (e.g. 
cosmetic changes, etc).
 
> I think that's where some of Igor's frustration stems from.  I know it's
> a frustration of mine.
> 
> Philip

But it is an unfounded frustration, as your understanding of the policy is
incorrect.


-- 
Eric Rostetter