[Setools] bug tracking system for Squeak

[Stéphane Ducasse]

On 14 août 06, at 09:08, goran at krampe.se wrote:

> 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

no why would it?

>> 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.

But I think that the process should be more or less the same.

> 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?

If new means that the bug is just declare but not accepted/confirmed,
Yes because reopen means that it was already accepted as a bug.


> - Not sure if we need the two distinction stages UNCONFIRMED and NEW
> either.

I guess we need since someone can post a bug that is not one and the  
dispatcher should
reject it.

> But in general, having an "inbox" stage like NEW is fine.

No since you cannot sort what is new from what have been accepted as  
a bug.
For example a bug report without report.

> 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.

For that I have to think

>
>> 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.

Yeap.
No complex system.

I would like to start small but cover all the aspect (-> storage of  
information because just having a nice UI will not work)
>
> regards, Göran
> _______________________________________________
> Setools mailing list
> Setools at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/setools