[Setools] bug tracking system for Squeak

[goran at krampe.se]

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.

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