[Setools] bug tracking system for Squeak

[Stéphane Ducasse]

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