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) =========
What I would like to see is the summary view colours indicating exactly what will happen to the fix.
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
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
release@lists.squeakfoundation.org