{Spam?} Re: {Dangerous Content?} Job offer
Christian Robottom Reis
kiko at async.com.br
Thu Oct 30 13:46:10 UTC 2003
On Fri, Oct 24, 2003 at 02:18:30PM -0500, Steven Suson wrote:
> An ECR is a (more or less) vanilla bugzilla bug. FIXED means that in
> house, the problem/request has been corrected. The ECN encompasses
> documenting what needs to be done to get the fix into the field, as well
> as notify the field what the changes are, etc.
So why not have the ECN be a dependent bug on the ECR itself, and use
the ECN bug to handle requests to the relevant departments?
A possible workflow:
- Engineer closes ECR. Opens ECN bug (we could hack the UI to
provide a single link to do this, or we could do something when
the ECR is marked as fixed). ECN is marked as a dependent of the
ECR.
- Requests are placed on the ECN bug (automatically, if we do
backend work) for the standard requirements. It might be possible
to use untargeted requests, depending on your scenario.
- ECN bug is fixed, and the ECR bug can be Verified/Closed.
Variations of this workflow might include using a custom status READY
and making the ECR depend *on* the ECN to be FIXED, or something in that
line (inverting the dependency order).
> >Do the ECNs need to be individually numbered, or could they be seen as a
> >natural part of ECR resolution?
> >
> They are natural part of the ECR's which become RESOLVED/FIXED. However,
> I guess it's my turn to miss something, because I really don't see how
> Requests are applicable.
Well, Requests allow you to specify a discrete action (we use it on bmo
for review and approval requests, for instance) that is granted or
performed by a specific person. From what I understood, there are
multiple "deliverables" for each ECN, which you may be able to model as
requests, but maybe I'm not seeing the picture clearly here.
Do you store the actual deliverables as attachments in the ECN?
Take care,
--
Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331
More information about the developers
mailing list