Hi Jef,
On Wed, 2004-03-03 at 19:57, Jef Spaleta wrote:
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"
I would expect that any doc like this would be initially written up by
some person, posted to this list, argued over by package maintainers,
developers and shepherders alike and over time massaged into something
everybody pretty much agrees on. I think you could easily christen
something like that as a "policy" :-)
> 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.
That's why even a rough set of notes keeping track of stuff like this
would be helpful for when someone does have the time to try and codify
it properly.
> <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.
Agreed. Totally. What I'm trying to get it is the "policy" is probably
nearly as undefined and confusing for developers as it is for triagers.
So any "policy" doc would help everyone. And FWIW, what you just said
would itself be very useful in such a doc.
Cheers,
Mark.