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)
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
