Adam Williamson wrote:
> There is one type of feedback we don't really want or need to capture:
> "I have tried this update and it doesn't fix bug #XXXXXX", where the
> update doesn't claim to fix that bug. This is a quite common '-1' in the
> current system, and one we should eliminate.
Indeed, those are clearly invalid -1 comments and need to stop.
> I think Bill's proposed policy can be modified quite easily to fit this.
> All it would need to say is that for 'important' updates to be accepted,
> they would need to have one 'type 1' feedback from a proven tester, and
> no 'type 2' feedback from anyone (or something along those lines; this
> isn't the main thrust of my post, please don't sidetrack it too
> much :>).
where
> 2. I have tried this update in my regular day-to-day use and seen a
> regression: bug #XXXXXX.
The problem is that type 2 feedback can also be invalid, e.g.:
* the regression may actually be caused by another update which is not part
of the update group being commented on,
* the regression may be caused by an earlier update which is already stable,
the user just didn't notice it right away (so this is actually a "doesn't
fix a bug which the update doesn't claim it fixes" situation, not a
regression; delaying or blocking the update does nothing to fix the
regression which already slipped through to stable),
* the "regression" may actually be an issue with:
- yum or PackageKit (usually already fixed, but the user needs to update yum
or PackageKit first),
- the user's setup (invalid repository configuration, attempts to mix
different versions of a multilib package etc.),
- mirroring or some other networking issue completely unrelated to the
update,
etc.
IIRC, we've had all of these happen for KDE updates.
In addition, there is a potential for this feature being abused for DoS
attacks in the future, especially if it gets such a big significance.
So I don't think blocking an update outright for having received type 2
feedback is sane at all.
Kevin Kofler
--
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
