[QA] To clone or not to clone ( a bug report ) that's the question...

[Kevin Kofler]

Jesse Keating wrote:
> Then that just means our rawhide bug lingers open even when it may be
> fixed, which throws off trackers and blockers and queries.  Not a
> solution.

Then push the fix out to releases sooner, maybe even directly to stable if
it's important enough to be on the tracker for the next release. Why would
it be so important as to block the next release and not worth being fixed
in the current one ASAP (unless the current one is not affected at all,
which is exactly when you'd use CLOSED RAWHIDE)?

>> >   3) bodhi auto-closing.  Not every update gets pushed at the same
>> >   time,
>> 
>> Then that's the issue to solve.
> 
> Right, and how do you propose we "solve" this (not that I agree that
> this is a problem)?

By pushing the updates out to the releases at the same time.

> At the same time doesn't work.  What if your attempted fix on F-9 fails,
> but the fix on F-10 succeeds?  Should the F-10 build sit in
> updates-testing until the say that F-9 works?  F-10 users just suffer
> for the sake of having the push go at the same time?  Ridiculous.

Well, in the cases I've seen, we just used the same fix everywhere, so I
don't see why it would work in one release and not the other. Generally, I
just wait for the first positive feedback on any release or for a week or
two without negative feedback and then push it to stable on all releases.
Waiting for feedback on all releases is a lost cause (except for some
packages like the kernel, but feedback there generally gets ignored
altogether), we already have to be happy to get any feedback at all. Having
bugfixes stalled in testing for ages doesn't help anyone.

> You can always opt out of having triagers touch KDE bugs.

Well, our KDE triager is doing good work and is also working with KDE SIG,
so I'm sure we can have him follow KDE-specific policies and the other
triagers rarely ever touch KDE bugs. But I'd rather policies weren't
radically different across components. Inconsistencies confuse everyone.
For example, not everything I maintain or comaintain is a KDE package.
Reporters, triagers and maintainers will be working with packages from
unfamiliar components occasionally, differing policies will confuse them
pretty quickly. That's why I think consistency is important (and also why
I'm complaining about the security team following a policy to clone bugs
for each release when almost nobody else is doing that).

        Kevin Kofler