[Setools] bug tracking system for Squeak

[goran at krampe.se]

Hi!

florent trolat <trolat.florent at laposte.net> wrote:
> I'm working on a new bug tracking system for Squeak. (SummerTalk 2006 
> mentor S Ducasse :-) )

I would actually first try to define what you mean by "for Squeak". Do
you mean for development of the "kernel" only or a service meant to
support all the external packages too? And if both, should such a system
work differently for those two layers? etc
 
> a first step for this project is certainly to open a brainstorming
> 1/
> about  the features you need with a bug tracking sytem.

I can gladly list what I think is important to support the current
Squeak community (kernel and packages) - but the above questions needs
answering I think.

The kernel could probably handle a more elaborate model than the
packages group could. But this also depends on what developers have the
ball - there is a small group that currently is driving 3.9 (which seems
like the best approach for the moment with Traits and all) but the next
release might get organized differently.

Three obvious general things though: Good email support, Squeak
integration and Simplicity.

> 2/
> Bugzilla give me a start point to make a stupid first workflow graph of 
> our new bug tracking system :
> http://membres.lycos.fr/artemice/
> 
> what's your opinions?

To be honest - first I thought it looked too complex for the Squeak
public community. But now I looked it over again and perhaps I was
wrong, it seems kinda ok. If it can be simplified a bit more then it
would be great:

- Do we need the stages REOPEN and NEW to be two different stages?
- Not sure if we need the two distinction stages UNCONFIRMED and NEW
either.

But in general, having an "inbox" stage like NEW is fine. Then having a
different stage when someone takes responsibility of it is also good.
The thre stage process with resolved/verified/closed also seems fine,
even though I might argue for one less stage there: resolved followed by
closed when verified by the reporter or when the reporter does not seem
to get back to it - by someone else.

> 3/
> we need to defined a hierarchy for all the users of this sytem : admin, 
> MasterProgrammer, Begginer....
> Some Ideas?

As flat as possible. Squeak is an open source community - we generally
dislike hierarchies and we do not really have any. I would argue for
just having:

- A small group of admins with full rights.
- Package owners might possibly have more rights regarding the cases
filed for their packages.
- All the rest.
 
regards, Göran