package shepherding

[Jef Spaleta]

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