[Setools] bug tracking system for Squeak

Mon Aug 14 22:49:11 UTC 2006

Hi,

Thank you for your interrest!

I would link this discution with another on sqeak-dev :
-------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------
Stéphane Ducasse a écrit :
> hi all
>
> here are some brainstorming about how we could use gjallar to manage 
> bugs fix and todo for smalltalk applications. We need inputs
> since we would like that the community takes benefit of it.
>
> Here is a draft of Compass (you can also propose a better name)
>
> A group of people (everybody but would be good that people register 
> first) can declare bugs or todo = we should give them a name
> Bugfinders
>     A group of people (the same) can comment give feedback, tests, fix
> Bugfinder
>
> A different group of people (the dispatchers)
>     - can assign bugs to project
>     - discard them
>     - filter them
>     - change the bugs status
>
'Project' seems to be new for me... may be Bugfinders are members of one 
or several projects? after the dispatch the bugs are assigned by 1 
bugFinder to himself ?

1 bug => 1 bugFinder or * bugFinders?

> A group of people
>     - ...
>     - can assign the bug to himself
this kind of people become bugFinder in this case?
>
> A bugfinder can close its own bugs since it may be a mistake
>
> A package responsible/image
>     - is a dispatcher that can
>         - close bugs
>         - reissue them
So the dispatchers can move bugs inside the workflow but there are 
particular jumps that only the package responsible can induce ?

Stef

---------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------

>
> On 14 août 06, at 12:29, goran at krampe.se wrote:
>
>> Hi!
>>
>> Note: I just saw (after having written the text below) that I have been
>> discussing the Bugzilla graph (at the bottom) instead of Florent's
>> proposed graph (at the top at: http://membres.lycos.fr/artemice/). My
>> mistake.
>
> No problem
> Indeed the process seems a bit too complicated.
>
> Stef
... my first process is just a start point to discuss... I've no 
experience about squeak devellepoment so I need you desperately ;-)

>>
>> =?ISO-8859-1?Q?St=E9phane_Ducasse?= <stephane.ducasse at univ-savoie.fr>
>> wrote:
>>> 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?
>>
>> Well, it depends. :) If the kernel is worked on by a group that has
>> taken upon themselves to make a new release within say a year - then
>> they have kinda allocated time and energy and commitment to that task.
>>
>> Many package maintainers on the other hand are "idling" because they
>> have released packages that works pretty good and issues are reported
>> seldomly - and they have not typically allocated time and energy to
>> handle a sudden flurry of activity.
>>
>> Or in other words: The current release team of the kernel probably scans
>> Mantis every other week/day, but the average package maintainer can
>> hardly even the URL to Mantis in his head.
>>
>> In short - the two tasks/groups are different and *perhaps* they need
>> different models. I am not saying it *is* so, I am just humble to the
>> possibility. :)
>>
>> For exampe, I think the process for package maintainers should be driven
>> largely by email - we can not assume they scan the web UI. I would also
>> assume that package maintainers will work in "larger chunks". Now and
>> then they grab a bunch of cases and just fix them, but they do not
>> typically micro-maintain the cases by moving them forward in small steps
>> in the workflow that only means they are doing different things
>> (confirming, working, verifying 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.
>>>
>>> But I think that the process should be more or less the same.
>>
>> Hopefully yes, just mentioning that it might be different.
>>
>>>> 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.
>>
>> Mmmm, but NEW means that it is confirmed (otherwise, what does
>> UNCONFIRMED mean?)
>> I can't see much difference between NEW and REOPEN, except for the fact
>> that it shows it has been reopened - but in Gjallar we have full history
>> anyway so that fact is not lost.
>>
>>>> - 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.
>>
>> Well, you can still reject it by moving it to CLOSED.
>>
>>>> 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.
>>
>> Well, I would think that accepting something as a bug and not assigning
>> it to someone is a bit odd anyway. So if it is in ASSIGNED then I
>> consider it to be "accepted".
>>
>>>> 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
>>
>> I am not saying the proposed model doesn't work - I just would like to
>> start with a model which is as simple as POSSIBLE and then we can easily
>> add more stages and transitions as we go (Gjallar allows that fine). I
>> think that having a QA phase is overkill.
>>
>>>>> 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 
but to work better and faster we need organization (vs hierarchies) ...
Goran idea of the user organization seems to be compatible with the 
Steph description on sqeak dev...

....

>>>> just having:
>>>>
>>>> - A small group of admins with full rights.
Yes but who decide who begin admin ? (may be everybody begin admin if 
he/she want)
>>>> - Package owners might possibly have more rights regarding the cases
>>>> filed for their packages.
>>>> - All the rest.
>>>
>>> Yeap.
>>> No complex system.
Ok , what's your opinion about "veriefied" stage :  this action needs 
several persons?
>>>
>>> I would like to start small but cover all the aspect (-> storage of
>>> information because just having a nice UI will not work)
>>
>> I would rather caution us to not create a complex model because it will
>> just turn people off. If we decide later that hey, we really NEED an
>> extra stage here and there - then we add it. The model is never better
>> than the people filling it all in. :)
>>
>> regards, Göran
>> _______________________________________________
>> Setools mailing list
>> Setools at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/mailman/listinfo/setools
>
> _______________________________________________
> Setools mailing list
> Setools at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/setools