{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