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

[Jesse Keating]

On Thu, 2009-01-22 at 13:08 +0100, Kevin Kofler wrote:
> 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)?

Again because the fix for rawhide vs a release tree may be different, as
the versions are different.  Also the fix needs to be in -testing on the
release tree to make sure that the fix integrates well with the other
software, whereas it needs to go out in rawhide immediately.  I really
think you're stuck in the mindset of same software on every branch,
which just isn't and shouldn't be the case for everybody.

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

Gee it's so simple.  The hat goes on the head! </sarcasm>

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

Because for a lot of people, software is /different/ on one release vs
the other.  Particularly software that is used by lots of other things.

>  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
> 
-- 
Jesse Keating RHCE      (http://jkeating.livejournal.com)
Fedora Project          (http://fedoraproject.org/wiki/JesseKeating)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
identi.ca               (http://identi.ca/jkeating)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090122/f9f76cbc/attachment.sig>