[Release] Re: Mantis automation

[Ken Causey]

On Wed, 2008-12-10 at 15:10 +0000, Keith Hodges wrote:
> Hi Ken, Matthew, Igor,
> 
> I am looking at automating more of our use of mantis. I think it would
> be nice if we could run code like that below: (assuming that no changes
> have been made to mantis so far)
> 
> =========
> Installer mantis select: [ :ea | ea isStatusConfirmed ] thenDo: [ :ea |
> ea ensureFix ].
> 
> self isUnstable ifTrue:
> 
> [ Installer mantis select: [ :ea | ea isStatusAcknowledged ] thenDo: [
> :ea | ea ensureFix ] ].
> 
> (the actual code will be more complex, because we will want to pay
> attention to dependencies)
> =========

From the IRC conversation I understood there was an additional 'testing'
level: testing, unstable, stable (aka release?)

> What I would like to see is the summary view colours indicating exactly
> what will happen to the fix.

See where?

> Colours/Levels desired are:
> 
> 1 A fix script is available (assigned / fix-script-available)
> 2 fix is included in the unstable build (acknowledged / unstable)
> 3 fix is included in the stable build (confirmed / stable)
> 4 fix is in a release (resolved)
> 
> One problem with this idea is that if you want to request  discussion on
> a fix then moving it to "feedback" will pull it out of the build,
> (perhaps that is not a bad thing)
> 
> Item 1, on the list didn't seem to be important enough to require a
> colour of its own. Furthermore I felt it would be good to have some way
> for the writer of the fix to indicate his level of confidence in the fix.
> 
> i.e. "I think this should go in to the stable build", I thought that we
> could use the resolved field for this. i.e "open" "fix available" "fix
> needs testing" "fix is good to go" "fix is deployed" i.e. "fixed".
> 
> Another possibility, which is perhaps easier to use is to have "special
> users"
> 
> Assign to user "Rel-inbox"   - fix available
> Assign to user  "Rel-testing" - fix is suitable for the unstable build
> Assign to user  "Rel-outbox" - fix should be in the stable build.
> 
> hopefully that's a bit clearer
> 
> so given that the special users idea gives me the extra features that I
> want, shall we go with this.
> However it might be useful to put a explanation on the front page.
> 
> thanks
> 
> Keith

What I was really wanting to see from you at this step is your idea of
the overal process, from a human standpoint: the various phases of an
issue and who is involved in each step.  To move thing along I will
write up my idea combined with my current understanding of your goals,
please correct and modify as appropriate.

First I need to posit some people:

Reporter: The person who submits the issue

Fixer(s): 1 or more person who supply a fix in harvestable form

Harvester: A person who decides that a fix is targetable for one or more
release artifacts.

Issue States and State Changes: (note the numbers are primarily for
short identification and not order, a states may be re-entered and may
move to any of several states)

  1. Newly reported
    Entered By: Reporter
    Next Status: 2 by: anyone
    Next Status: 8 by: Reporter or Harvester
    Next Status: 3 by: Fixer

  2. Discussion
    Next Status: 3 by: Fixer
    Next Status: 8 by: Reporter or Harvester

  3. Fix added
    Next Status: 4 by: Harvester
    Next Status: 8 by: Reporter or Harvester

  4. Fix accepted for Testing
    Next Status: 5 by: Harvester
    Next Status: 3 by: Harvester
    Next Status: 8 by: Reporter or Harvester

  5. Fix accepted for Unstable
    Next Status: 6 by: Harvester
    Next Status: 4 by: Harvester
    Next Status: 3 by: Harvester
    Next Status: 8 by: Reporter or Harvester

  6. Fix accepted for Stable
    Next Status: 7 by: Harvester
    Next Status: 5 by: Harvester
    Next Status: 4 by: Harvester
    Next Status: 3 by: Harvester
    Next Status: 8 by: Reporter or Harvester
 
  7. Issue Closed with Fixed in Release Status
    No status changes after this state

  8. Fix closed as non-issue, mistake, not to be fixed, etc.
    Next Status: 1 by: Harvester
    Next Status: 3 by: Harvester or Fixer
    Next Status: 4 by: Harvester

Ken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/release/attachments/20081211/ec80ca7e/attachment.pgp