Mark McLoughlin wrote: > Yeah, I can appreciate that - I'm still figuring it out too. It > would be good though if we could have a general > "bugzilla.redhat.com policy" doc or something. Would you have the > time to start compiling that? No, I don't have time, but its near the top of the list of things i don't have time for. I'm desperately in search for a sucker..err volunteer that is interested in producing documentation, so I don't have to keep pretending like i know what I'm doing. And I think, considering how things are actually developing, it probably a stretch to call any document of this sort that i might write "policy" in the sense that developers are actually going to be encouraged by leadership to follow what's written. At best its more like "Jef's bugzilla for dummies" or "Jef's fireside bugzilla ghost stories" as a companion piece to "Jef's 12 easy steps to applying cat herding techniques to open source developer management" > e.g. we were discussing today on irc whether its valid to mark a > RHEL bug as a dup of a Fedora bug. The conclusion we came to was: You are going to hate me, as much as I like see exactly this sort of discussion, and I'm more than happy to take the fruits of discussion that I'm not actively involved with(I'm an invented anywhere but by me sort of person)...its very difficult to actually keep track with nuggets of information like this if I have to pick them up from the fedora-devel-list. I will lose track of them in the noise on the list, guaranteed. I'd tell you to subscribe to the not really used triage list and post there but I don't know if you really want to be a part of yet another list...so if you really want to make sure I see this sort of discussion about what to do about classes of bugs it might be best for you to email me directly with a clever topic that i can filter, like "Fedora Triage: much ado about RHEL bugs or other such descriptive text". > <markmc> if its sufficient to be fixed in a future release > <markmc> mark it as a dup > <markmc> if it needs to be fixed now, then leave it open > <markmc> and include a link to the dup These are the sort of judgement calls that are difficult to codify. And really require active discussion between package maintainer and the triagers who want to help with a specific package. Don't really want to encourage a situation where a triager is deciding what should and should not be fixed now without feedback from the maintainer, and conversely don't want to encourage a situation where a triager is demanding a significant amount of time from developers to get feedback about whether or not a collection of bugs are close now or keep open. As guidance for developers and package maintainers this makes sense. As guidance for triagers looking to help maintainers, this is probably not something i want to start with. -jef
