Updating Mantis status

Updating Mantis status
   was Meeting with Edgar notes
from nicolas cellier's reply
http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-February/124919.html

> nicolas wrote(at the end):
>
>And please, update Mantis status, current management
is a mess (issues
>harvested but status not updated).

This indeed deserves some attention.

Part of the problem is that mantis is a new tool for
most of the sqeuak community.
We are still learning how to use it effectively.

Managing it well will take several steps and a few
more iterations.

What would help:

1) clearly STATED roles and expectations.
  What updating of status is the responsibility of the
harvesters?
  What status should a report be in before a harvester
looks at it?

  What is expected of reporters?
  What is expected of updaters?
  What is expected of developers?

When should an issue be marked resolved?
When should it be marked closed?

2)Mantis allows customizing the names and number of
statuses. Our workflow and the way we use the current
ones probably requires a few more.
Who can we give the role of deciding and implementing
those additions. (Hi Ken :-)



3) How do we group issues together so that someone
fixing one can be aware of the others it might impact?

I started doing what I thought should be done. Matthew
Fulmer caught on and ran with it.

The thing is we can get a lot more work out of mantis
if give a little thought as to how it can assist our
work flow. We have right now accepted the defaults as
our limitations. This is not ideal.

4) Where do we discuss issues of how to use mantis
better?

5) OPLC Etoys has an etoys-notify list where their bug
tracker can send email about bug issues.
(auto-mail is much to boring for a converstational
list like squeak-dev)
Would it would be useful to have such a list?
Would their be folks who would follow it?

Yours in curiosity and service, --Jeorme Peace










      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping

On Thu, 2008-02-07 at 17:39 -0800, Jerome Peace wrote:
> Part of the problem is that mantis is a new tool for
> most of the sqeuak community.
> We are still learning how to use it effectively.

Which, while perhaps true, is really rather sad since it has been in use
now for over 3 years.

> Managing it well will take several steps and a few
> more iterations.
>
> What would help:
>
> 1) clearly STATED roles and expectations.
>   What updating of status is the responsibility of the
> harvesters?

Huh?  I'm afraid I can't parse that.

>   What status should a report be in before a harvester
> looks at it?

I'm going to assume for the moment that by 'harvesters' you mean the
release team, as that terminology has been largely dropped for regular
usage.

I'm afraid that in practice the harvesters can't assume anything about
status.  If someone creates a new report and even attaches a fix, it may
well be the case that this issue is ready for 'harvesting' even though
no one else has looked at the issue.   It would be nice to have another
step in the process before that, but there do not seem to be enough
eyeballs available.  In the end the release team has to answer this for
themselves.

>   What is expected of reporters?

To just fill out the report form as best they can.  The details of that
can be found in the project documentation at

http://bugs.squeak.org/proj_doc_page.php

(Unfortunately at least in some browsers you may be expected to start
another application to view what is in fact an HTML page.  Of course you
can do that or even simply save it and open it as a local file.  I guess
this is next on my todo list after having completed passphrase resetting
support on Squeak People.)

>   What is expected of updaters?

Who?

>   What is expected of developers?

Again who?

> When should an issue be marked resolved?

If it is decided that the issue is not to be fixed for whatever reason
then immediately.  Otherwise assuming a fix is supplied then the release
team should mark the issue resolved once the fix is placed within the
current version of the update stream and they should annotate the report
with some sort of identifier for the fix as it appears in the update
stream, currently the update stream number would be sufficient.

> When should it be marked closed?

If the issue has been marked as resolved because there is to be no fix
and the release team either made that decision themselves or are
satisfied with that decision then they can go ahead and close the issue.
If a fix has been supplied and is accepted then when the release team
issues an image that includes the fix or possibly after the entire
alpha/beta/gamma process for a version where that version contains the
fix.  Either would be fine by me.

> 2)Mantis allows customizing the names and number of
> statuses. Our workflow and the way we use the current
> ones probably requires a few more.
> Who can we give the role of deciding and implementing
> those additions. (Hi Ken :-)

This has been discussed before and I've already said that I'm more or
less happy with them but that I would welcome suggestions.  I don't
remember ever receiving any.

> 3) How do we group issues together so that someone
> fixing one can be aware of the others it might impact?

Each Mantis report can have a relationship to one or more other issues,
this is on the report page in a section entitled Relationships just
under the main details section and above the upload section and
comments.
Is there something wrong with this mailing list?

> 5) OPLC Etoys has an etoys-notify list where their bug
> tracker can send email about bug issues.
> (auto-mail is much to boring for a converstational
> list like squeak-dev)
> Would it would be useful to have such a list?
> Would their be folks who would follow it?

I'll have to leave these to others to answer.

>
> Yours in curiosity and service, --Jeorme Peace

Ken

Updating Mantis status

HI Ken,

Thanks for your prompt response.


***
>Ken Causey ken at kencausey.com
>Fri Feb 8 02:32:43 UTC 2008
>
>
>
>On Thu, 2008-02-07 at 17:39 -0800, Jerome Peace
wrote:
>> Part of the problem is that mantis is a new tool
for
>> most of the sqeuak community.
>> We are still learning how to use it effectively.
>
>Which, while perhaps true, is really rather sad since
it has been in use
>now for over 3 years.
>
Ummh. It takes a community longer to learn than an
individual. And it takes some motivation.
I have been using mantis to report 200+ issues and I
comment on those others have posted.

I started with some knowledge and gained bits and
pieces with use.

Few others have used it as much, so it is not
surprising that they have not learned the extent of
mantis's abilities.

The motivation is that if we want an improved base
squeak we need someway to communicate
1) what is not working,
2) find clues and analyze why it doesn't work,
3) propose fixes,
4) convince others those fixes are correct and
5) will integrate well into squeaks present code base
and future direction.
6) finally that those fixes have been noticed
7) incorperated into a particular release or squeak

8) Once all that is done the issue stays around as
part of the collective history and documentation
and stands ready to provide clues for solutions to
future problems.

The also stands as a description of the work flow.
With the reporter responsible for 1, and optionally 2,
3(in the form of code) and 4,5 (in the form of tests).
When the work gets to 6,7 that must be either a
package steward or a release team member or both.

Between 7 and 8 I have left out the steps that happen
when feedback comes from the test pilots of a release.
The fact is many fixes that get in don't work once
they are in the system. There can be unforseen
integration problems or the fix may not actually work
as advertised. This is especially true because the
stewards or release team may favor a fix even when
tests have not been provided. And because squeak has a
great maintenence debt in the form of a lack of test
coverage for code that already exists. I track bugs.
My job is like shooting fish in a barrel.



>> Managing it well will take several steps and a few
>> more iterations.
>>
>> What would help:
>>
>> 1) clearly STATED roles and expectations.
>>   What updating of status is the responsibility of
the
>> harvesters?
>
>Huh?  I'm afraid I can't parse that.

 Sorry, I've given this a lot of thought which didn't
fit into the post. This has to do with work flow.
When a stewart or release team harvests a fix then do
they have the responsibility for updating the mantis
reports status to resolved or closed from open or
assigned?
>
>>   What status should a report be in before a
harvester
>> looks at it?
>
>I'm going to assume for the moment that by
'harvesters' you mean the
>release team, as that terminology has been largely
dropped for regular
>usage.

Yes. But we haven't had a scheme for dealing with
releases that has lasted long enough for the
terminology to stick.
>
>I'm afraid that in practice the harvesters can't
assume anything about
>status.  If someone creates a new report and even
attaches a fix, it may
>well be the case that this issue is ready for
'harvesting' even though
>no one else has looked at the issue.  

The way we do it now, yes. But we could add statuses
that indicate the issue has a fix attached.
And another that it has tests to prove the fix is
necessary and sufficient; has been reviewed by at
least a second person. And has nothing more to do
except wait to be "harvested" into an current image.

It would be nice to have another
>step in the process before that, but there do not
seem to be enough
>eyeballs available.

Partial progress counts. If we make this process as
good as we can there is always the change it would hit
the tipping point.

>In the end the release team has to answer this for
>themselves.

Yes. and it shouldn't be to hard to reach guidelines
that let them know what they are expected and counted
on to do to keep the communications clear. We also owe
it to them to make there job as easy as possible
because we must count on them for a great deal.
>
>>   What is expected of reporters?
>
>To just fill out the report form as best they can.
The details of that
>can be found in the project documentation at
>
>http://bugs.squeak.org/proj_doc_page.php
>
>(Unfortunately at least in some browsers you may be
expected to start
>another application to view what is in fact an HTML
page.  Of course you
>can do that or even simply save it and open it as a
local file.  I guess
>this is next on my todo list after having completed
passphrase resetting
>support on Squeak People.)
>
>>   What is expected of updaters?
>
>Who?
You have given people either reporter status or
developer status. Mantis provides for a status
inbetween that called updaters. People who have some
abilities to update issues but not as much as
developers.

Since we have no updaters who are not also developers,
updater is just a role for someone with updater
abilities or better.


>
>>   What is expected of developers?
>
>Again who?
I am using the mantis terms for different priveledges
with regard to the system
observer, reporter, updater, developer, administrator
(and I may have missed one.)

>
>> When should an issue be marked resolved?
>
>If it is decided that the issue is not to be fixed
for whatever reason
>then immediately.  Otherwise assuming a fix is
supplied then the release
>team should mark the issue resolved once the fix is
placed within the
>current version of the update stream and they should
annotate the report
>with some sort of identifier for the fix as it
appears in the update
>stream, currently the update stream number would be
sufficient.
>
See now you are answering my earlier question about
their roles.

>> When should it be marked closed?
>
>If the issue has been marked as resolved because
there is to be no fix
>and the release team either made that decision
themselves or are
>satisfied with that decision then they can go ahead
and close the issue.
>If a fix has been supplied and is accepted then when
the release team
>issues an image that includes the fix or possibly
after the entire
>alpha/beta/gamma process for a version where that
version contains the
>fix.  Either would be fine by me.
>
>> 2)Mantis allows customizing the names and number of
>> statuses. Our workflow and the way we use the
current
>> ones probably requires a few more.
>> Who can we give the role of deciding and
implementing
>> those additions. (Hi Ken :-)
>
>This has been discussed before and I've already said
that I'm more or
>less happy with them but that I would welcome
suggestions.  I don't
>remember ever receiving any.
>
I am just about to the point where I can make some. I
didn't want to suggest answers at the same time as I
asked questions.


>> 3) How do we group issues together so that someone
>> fixing one can be aware of the others it might
impact?
>
>Each Mantis report can have a relationship to one or
more other issues,
>this is on the report page in a section entitled
Relationships just
>under the main details section and above the upload
section and
>comments.
>
Yes. My question was more on the order of, having this
ability what is the best way to use it consistently?
Mantis will also allow us to name are own
relationships between reports beyond what they supply.
I can think of a few that might be useful.
>>
>> I started doing what I thought should be done.
Matthew
>> Fulmer caught on and ran with it.
>>
>> The thing is we can get a lot more work out of
mantis
>> if give a little thought as to how it can assist
our
>> work flow. We have right now accepted the defaults
as
>> our limitations. This is not ideal.
>>
>> 4) Where do we discuss issues of how to use mantis
>> better?
>
>Is there something wrong with this mailing list?

That's a good question.  What do others think?
>
>> 5) OPLC Etoys has an etoys-notify list where their
bug
>> tracker can send email about bug issues.
>> (auto-mail is much to boring for a converstational
>> list like squeak-dev)
>> Would it would be useful to have such a list?
>> Would their be folks who would follow it?
>
>I'll have to leave these to others to answer.
>

Yeah, me too.

Yours in curiosity and service, --Jerome Peace

>
***



      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page.
http://www.yahoo.com/r/hs

El 2/7/08 11:32 PM, "Ken Causey" <[hidden email]> escribió:


Sometimes I'm not sure which one, but now is clear when I put some like

> This now is 7156UnimpFixForM5285-wiz.cs and was in updates for 3.10
> Thanks Jerome !

in Mantis, then I should mark as resolved.
When we agree start 3.11, whatever this was, then all resolved should change
to closed if no new notes or new troubles.

>> 4) Where do we discuss issues of how to use mantis
>> better?
>
> Is there something wrong with this mailing list?

No.
But could go to release team list, at this moment means "Discussion about
development of Squeak 3.10" <[hidden email]>
This way, some less traffic here and people following Squeak fate could read
any news.

Edgar

From: Jerome Peace <[hidden email]>
>  Sorry, I've given this a lot of thought which didn't
> fit into the post. This has to do with work flow.

Seconded with a newbie's enthusiasm.

I'm more than a little confused about the Mantis workflow.  As an
example(*), consider http://bugs.squeak.org/view.php?id=3311, where an
individual identifies some lossage in the existing Complex class, then
proposes a replacement class addressing the identified problems.

In every project that I've known before, this would have been accepted
into some build, or else deferred, or else rejected outright.  (By whom?
  By some cabal or benevolent dictator.  All those projects have had
such.)  Instead, this fix has simply sat there, apparently without
comment, for the last two years.

So I don't really see how Mantis works(**).  Yes, there's a place to
report problems.  But do fixes come out of it?  If as part of a project
of mine I can address some open issues therein, will they ever reach the
mainstream?  May I just step in and claim a bug on my own, filing a
suggested fix for it?  Also, if as part of a project of mine I can
factor out some baseline kernel improvements, should I bother proposing
them in Mantis?  Or should I just dump those base-class amendments into
my package and let client handle the merge themselves?  A lot of the
latter takes place right now....

I'm not asking that anything change to accommodate my expectations.  I
just want to understand how to work here.

Cheers,
Ben


--
(*) Okay, I admit, it's not a random example -- I don't know Mantis that
well.  It's an issue that I know and care about.  But I'm not sending
this mail to flog that cause, really.

(**) Corollary: I don't really see how Squeak-the-project works.  And
yet, here it is!

El 2/8/08 7:11 AM, "Ben Goetter" <[hidden email]> escribió:


I remember the requeriments Ralph put for 3.10 (that's why less updates as
older Squeak releases)

>In general, changes will come through Mantis (the squeak bugs and changes
>management system). Ideally, a Mantis patch will be a [[Monticello]] package,
but we will also accept .cs files, though we will first convert them to .mcz
Monticello files. Ideally, changes will be approved by one of the stewards,
though if code does not have a steward or if the stewards are not responsive,
the release team will approve them.

All should come with test, and with other Squeaker saying this is a good
change.
Then
>   1. Loading bug tests before fixes.
>   2. Run the bug test. (It should fail)
>   3. Install the fix.
>   4. Run the bug test. (Now it should pass.)

All this and the most of 2000 Sunit test which I run on Mac, Windows XP and
Linux don't guarantee Squeak is Bug free.
We have cases on some bugs with long reports, cases of Monticello headaches
and my own mistakes.
But I put some old Mantis report on 3.10...

3.10 end, I wish start 3.11 and must wait some agree on my proposal or do
some better proposal.

Edgar

Ben Goetter wrote: Dear Ben,

The current process is such that a bug report and fix which hangs around
on mantis may at some point be harvested by an enthusiastic release team
member. In some cases it will attract the attention of someone who is
into bug harvesting, they will check its ok and point out to the release
team that it is ready. It is all very informal and actual process is
entirely dependent upon whatever the release team wants to do.

===
There are some up and coming improvements to this process...

Installer - Mantis Integration
====================

When you want to use or test a fix on mantis, append a note which
includes a script. The script indicates which of the uploaded files is
relevant. The script needs to be delimited like so.... e.g

"fix begin"
Installer mantis bug: 1234 fix: 'UploadedFile.1.cs'.
"fix test"
Installer mantis bug: 1234 fix: 'UploadedTest.1.cs'.
"fix end"

Given that the above script is in the mantis report, the following code
will load the fix changesets.

Installer mantis fixBug: 1234.
or
Installer mantis fixBug: '1234 Informal fix description'.

So if you use Installer scripts to build your working or deployment
images, mantis uploaded files may be loaded via this
method.                                              

Level Playing Field - Scripts
====================

The second part of this process is LevelPlayingField. If you want to
write a public script which loads MyPackage into any version of squeak,
you could put that script on http://installer.pbwiki.com/MyPackage, with
different versions of the script for different squeak image versions,
e.g. http://installer.pbwiki.com/MyPackage-Squeak3:10 . These scripts
are also installer scripts and so they can add the required bug fixes
before the main package code is loaded. In this case the delimeter is
<code st>... </code st>

<code st>
Installer mantis ensureFix: 1234.
Installer squeaksource project: 'MyPackage'; install: 'MyPackage'.
</code st>

Level Playing Field image maintenance.
============================

Level Playing Field has a slot to which minor fixes can be appended to
an image.
so...

http://installer.pbwiki.com/MinorFixes-Squeak3:10 is where you put fixes
which apply to Squeak3.10, However the process is to begin by putting
your fix in http:installer.pbwiki.com-Squeak3:80/MinorFixesUnstable to
start with, until folks have at least tried it out.

Then interested users can load the minor fixes via,

Installer install: 'MinorFixesUnstable'.
or
Installer install: 'LatestUnstable'.  (which includes MinorFixesUnstable).

So... testers can easily get all of the pending fixes into their image,
fixes which will be moved to MinorFixes if they are shown to be good.

The next release team can use  Latest as part of their process and the
benefit from fixes which have already been ratified by end users.

I hope this answers some of your questions. Feel free to join in and
contribute to MinorFixesUnstable , the password is, somewhat
predicabky,  'squeak'

best regards

Keith









                                                                   

 > I hope this answers some of your questions.

It does indeed. Thank you, Keith and Edgar.

Ben

On Thu, 2008-02-07 at 20:59 -0800, Jerome Peace wrote: What you say has some validity but it still seems like a very long time
to me.  Use of Mantis was really only meant to be temporary and I had
thought that by now we would have decided on another tool that would be
at least a better fit than any, including Mantis, that had come before.
Hope is on the horizon at least in the form of Gjallar and Delta Stream
and in work I believe is swimming around in the mind, at least, of Craig
Latta.
Yes they do.  They are not the only ones who can do this but in the case
where a fix/enh is actually harvested they should update the status and
enter at least terse notes that would allow anyone with a little
diligence to follow a chain either from code in an image back to the
original report or vice versa be able to find the issue in Mantis and
find the code that eventually made it into a release to address the
issue.  I like to think of it as a short doubly linked list.
Those 'roles' were defined by Mantis and not necessarily reflective of
our particular processes.  While I've considered it, I don't believe
anyone in fact is marked as an updater.  A developer is anyone who can
modify an existing report much beyond the status of adding a note or
attachment.

So in practice we only really use two of these roles.  Anyone who
registers is automatically given abilities to report issues, add fixes,
comment, etc.  This is enough for many people.  For those who need more
than this then they become 'developers'.

> Yours in curiosity and service, --Jerome Peace

Ken

El 2/8/08 3:28 PM, "Ken Causey" <[hidden email]> escribió:

> Use of Mantis was really only meant to be temporary and I had
> thought that by now we would have decided on another tool that would be
> at least a better fit than any, including Mantis, that had come before.
> Hope is on the horizon at least in the form of Gjallar and Delta Stream
> and in work I believe is swimming around in the mind, at least, of Craig
> Latta.

I have deep respect for Craig, Goran, Matthew and others working on this.

But...

If still people don't put bug reports in Mantis and few use it (from many
Squeakers), how you think they instantly use still unknown ?

Blaming Mantis don't help. It's useful.


Edgar

On Fri, 2008-02-08 at 16:42 -0300, Edgar J. De Cleene wrote: I'm not blaming Mantis.  From day one it was little more than a stopgap
measure.  That being said, the fact that use of it has not been taken up
more generally is surely evidence that it is not a natural fit.

Ken