reactos-general

[ros-general] Bug-tracking systems

[Casper H. <ch...@us...>]

It's time to look into bug-tracking systems for the ReactOS project. I
have set up two bug-tracking systems for testing. There is the popular
Bugzilla at:

http://reactos.wox.org/bugzilla/

and the newer Scarab at:

http://reactos.wox.org:8080/scarab/servlet/scarab/

Feel free to signup and try them out by entering test data in both
systems. All data will be deleted eventually.

Bugzilla is the most mature of the two. Scarab is 1.0 beta 6 and I have
noticed a few bugs in it. Bugzilla is perl based and Scarab is based on
Java servlet technology.

Having looked around the two systems, my vote goes to Scarab for the
following reasons:

* The Scarab UI is more intuitive and have a task based (kind of like
your usual Windows wizards) layout. Scarab guides you through your
tasks, whereas Bugzilla usually present all information in one big form
for you to fill out.

* Scarab has better online help. Help is always just one click away and
it opens in a new window whereas Bugzilla on some pages has a link to a
large page with information (i.e. you have to leave the page to get
help).

* In Scarab, you get all errors at once if you forget to fill out
required fields.

* Scarab is more generel in it's choice of names and more flexible. In
Bugzilla you create bug reports, in Scarab you create issues. In Scarab
you can define an issue called bug report and define your own attributes
for this issue (like description, sverity and status). You can even
define their input type (basicly how they are displayed) to string,
integer, drop-down list, etc. And best of all, they are searchable too!

In Bugzilla you have to do with the predefined attributes like platform,
summary and description.

* And finally, the Scarab UI look is kick ass nice ;o)

A feature that Bugzilla has that might be nice is graphing. Bugzilla has
a plugin module that will graph your bug reports with dependencies
between them. (Sorry, I could not install this module due to errors).
Scarab seems to not have such functionality.

Okay I've finished my speech, now let me hear yours.

Btw. Please continue this discussion on the ros-general mailing list.

Casper Hornstrup

Re: [ros-general] Bug-tracking systems

[KJK::Hyperion <no...@li...>]

At 14.53 05/05/2002, you wrote:

First of all, I've found a bug in Scarab: it doesn't prevent accidental 
double submission of an issue (double-click on the submit button). Maybe it 
should assign an internal non-sequential id/GUID to every issue in addition 
to the id (but it sounds more and more complicated as I write it)

>Bugzilla is perl based and Scarab is based on Java servlet technology.

Frankly, I don't give a damn ;-) Seriously, I think the only that should be 
worried about an implementation are the implementors (maintainers and 
contributors) and the deployers (administrators). We users don't care as 
long as it looks cool and it's easy to use ;-) Entirely your choice here, IMHO

>* The Scarab UI is more intuitive and have a task based (kind of like your 
>usual Windows wizards) layout. Scarab guides you through your tasks, 
>whereas Bugzilla usually present all information in one big form for you 
>to fill out.

Urk! the Bugzilla forms are huge and messy. They're enough to make you 
change your mind about filing a bug. Point for Scarab

>* Scarab has better online help. Help is always just one click away and it 
>opens in a new window whereas Bugzilla on some pages has a link to a large 
>page with information (i.e. you have to leave the page to get help).

Non-modal help rules. Point for Scarab

>* Scarab is more generel in it's choice of names and more flexible. In 
>Bugzilla you create bug reports, in Scarab you create issues. In Scarab 
>you can define an issue called bug report and define your own attributes 
>for this issue (like description, sverity and status). You can even define 
>their input type (basicly how they are displayed) to string, integer, 
>drop-down list, etc. And best of all, they are searchable too!

Actually, I find Scarab's terminology still very confusing. For example, in 
all bug tracking systems I come across, I measure how hard is finding out 
ALL bugs/issues in a module, sorted by date. Sadly, in Scarab it's still 
very counter-intuitive, and I have to resort to the help to find out how to 
do it

And some templates/schemas have to be customized for ReactOS. For example, 
the "operating system" attribute doesn't really make sense for issues in 
the core OS module ;-)

>* And finally, the Scarab UI look is kick ass nice ;o)

Right. I think it's even better than reactos.com's (personal opinion: those 
blurred bitmaps and pastel colors suck). Still, Wine HQ's site is cooler 
than both ;-)

We should (could?) standardize on a color/font scheme, for the web site and 
user interface. I mean, IBM has the white and deep blue, Microsoft has the 
sky blue and sand gray, Sun has the eggplant purple and gray, etc. We have 
a logo (well, if the radioactive warning symbol is definitive ;-), we miss 
a color scheme

Re: [ros-general] Bug-tracking systems

[Casper H. <ch...@us...>]

s=F8n, 2002-05-05 kl. 17:06 skrev KJK::Hyperion:
> At 14.53 05/05/2002, you wrote:
>=20
> First of all, I've found a bug in Scarab: it doesn't prevent accidental=20
> double submission of an issue (double-click on the submit button). Maybe =
it=20
> should assign an internal non-sequential id/GUID to every issue in additi=
on=20
> to the id (but it sounds more and more complicated as I write it)

Yes, this feature is missing.

>=20
> >Bugzilla is perl based and Scarab is based on Java servlet technology.
>=20
> Frankly, I don't give a damn ;-) Seriously, I think the only that should =
be=20
> worried about an implementation are the implementors (maintainers and=20
> contributors) and the deployers (administrators). We users don't care as=20
> long as it looks cool and it's easy to use ;-) Entirely your choice here,=
 IMHO

You are right about this.

> >* Scarab is more generel in it's choice of names and more flexible. In=20
> >Bugzilla you create bug reports, in Scarab you create issues. In Scarab=20
> >you can define an issue called bug report and define your own attributes=
=20
> >for this issue (like description, sverity and status). You can even defi=
ne=20
> >their input type (basicly how they are displayed) to string, integer,=20
> >drop-down list, etc. And best of all, they are searchable too!
>=20
> Actually, I find Scarab's terminology still very confusing. For example, =
in=20
> all bug tracking systems I come across, I measure how hard is finding out=
=20
> ALL bugs/issues in a module, sorted by date. Sadly, in Scarab it's still=20
> very counter-intuitive, and I have to resort to the help to find out how =
to=20
> do it

Having not used any bug-tracking system before I find neither of the two
terminologies harder than the other.

It seems that you can search for issues in a date range, but they only
be sorted by issue ID (ascending or descending). To see the creation
date for an issue you must click on it.

>=20
> And some templates/schemas have to be customized for ReactOS. For example=
,=20
> the "operating system" attribute doesn't really make sense for issues in=20
> the core OS module ;-)

Yes, the difference is that with Bugzilla we have to change the perl
code to remove this attribute. In Scarab, we just don't add it ;o)

>=20
> >* And finally, the Scarab UI look is kick ass nice ;o)
>=20
> Right. I think it's even better than reactos.com's (personal opinion: tho=
se=20
> blurred bitmaps and pastel colors suck). Still, Wine HQ's site is cooler=20
> than both ;-)
>=20
> We should (could?) standardize on a color/font scheme, for the web site a=
nd=20
> user interface. I mean, IBM has the white and deep blue, Microsoft has th=
e=20
> sky blue and sand gray, Sun has the eggplant purple and gray, etc. We hav=
e=20
> a logo (well, if the radioactive warning symbol is definitive ;-), we mis=
s=20
> a color scheme

I agree, is there an artist on the list?

Re: [ros-general] Bug-tracking systems

[KJK::Hyperion <no...@li...>]

At 17.47 05/05/2002, you wrote:
> > First of all, I've found a bug in Scarab: it doesn't prevent accidental
> > double submission of an issue (double-click on the submit button). 
> Maybe it
> > should assign an internal non-sequential id/GUID to every issue in 
> addition
> > to the id (but it sounds more and more complicated as I write it)
>Yes, this feature is missing.

I'm registering to tigris.org to submit bug reports

> > Actually, I find Scarab's terminology still very confusing. For 
> example, in
> > all bug tracking systems I come across, I measure how hard is finding out
> > ALL bugs/issues in a module, sorted by date. Sadly, in Scarab it's still
> > very counter-intuitive, and I have to resort to the help to find out 
> how to
> > do it
>Having not used any bug-tracking system before I find neither of the two 
>terminologies harder than the other.
>It seems that you can search for issues in a date range, but they only be 
>sorted by issue ID (ascending or descending). To see the creation date for 
>an issue you must click on it.

It's just that many may find hard to orient themselves in complex/obscure 
bug tracking systems. One may want to have a look at existing issues to 
make himself an idea on how a bug report looks like

> > We should (could?) standardize on a color/font scheme, for the web site 
> and
> > user interface. I mean, IBM has the white and deep blue, Microsoft has the
> > sky blue and sand gray, Sun has the eggplant purple and gray, etc. We have
> > a logo (well, if the radioactive warning symbol is definitive ;-), we miss
> > a color scheme
>I agree, is there an artist on the list?

I'm a bit of one myself (free-hand pencil sketching+inking, web design, 
printed and electronic promotional material design, some CGs, even a bit of 
3D modelling), but I *suck* at picking colors. And, above all, I definitely 
don't want to be involved in discussions/flames based on aesthetical taste 
(or lack thereof)

Jason, what about that guy that designed reactos.com? is he still 
available? not that the design is that bad, only it would be better if it 
was a bit more... professional. More sober, sharper edges, and with less colors

[ros-general] Re: [ros-kernel] Bug-tracking systems

[Jason F. <jas...@ya...>]

--- Casper Hornstrup <ch...@us...> wrote:
>It's time to look into bug-tracking systems for the ReactOS
>project. I have set up two bug-tracking systems for testing.

Ok I know.. my little reactos.org system has stalled - but I'm going
to give it more attention this week, really! And try and get it into
cvs.

>There is the popular Bugzilla at:
>and the newer Scarab at:

My main beef with most bug tracking systems is the way they view the
systems against which bugs are logged: as a list of components. The
idea behind rosproj (reactos.org system nickname) is that the system
is built up of a hierarchy, which more realistically models how
ReactOS is structured.

I really promise to try and get it in cvs this week.

- Jason









__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com

[ros-general] Re: [ros-kernel] Bug-tracking systems

[Casper H. <ch...@us...>]

s=F8n, 2002-05-05 kl. 18:23 skrev Jason Filby:
> --- Casper Hornstrup <ch...@us...> wrote:
> >It's time to look into bug-tracking systems for the ReactOS
> >project. I have set up two bug-tracking systems for testing.
>=20
> Ok I know.. my little reactos.org system has stalled - but I'm going
> to give it more attention this week, really! And try and get it into
> cvs.
>=20
> >There is the popular Bugzilla at:
> >and the newer Scarab at:
>=20
> My main beef with most bug tracking systems is the way they view the
> systems against which bugs are logged: as a list of components. The
> idea behind rosproj (reactos.org system nickname) is that the system
> is built up of a hierarchy, which more realistically models how
> ReactOS is structured.
>=20
> I really promise to try and get it in cvs this week.
>=20
> - Jason

We should be careful not to loose focus here. After all, ReactOS is an
operating system project and not a
miscellaneous-project-management-tools project. By creating all tools
ourselves...yes we can tailor them to our needs, but it does not come
cheap. First we have to create the tools, but even if they were created,
we would have to maintain them. All new features, we have to write
ourselves. If we choose a seperate project...yes we would depend on this
project, but we would gain access to all future updates for free and can
focus on improving ReactOS instead. If we need better integration, we
can choose projects which has taken this into consideration.=20

If anyone wants administrator rights on Scarab (and bugzilla too if
needed - and it is possible), please mail me with you username. Then I
will give you full rights to the test system so you can try modeling the
system.

Casper Hornstrup

[ros-general] RE: [ros-kernel] Bug-tracking systems

[Steven E. <Ste...@ya...>]

The box that will be reactos.org is up and going at reactos.dhs.org.

I will move the current application and driver db code there if you
havent already rewritten it in php.

Steven

"Every revolution was once a thought in one man's mind"
- Ralph Waldo Emerson 

> -----Original Message-----
> From: rea...@li... 
> [mailto:rea...@li...] On Behalf 
> Of Jason Filby
> Sent: Sunday, May 05, 2002 12:23 PM
> To: Casper Hornstrup; rea...@li...
> Cc: rea...@li...
> Subject: Re: [ros-kernel] Bug-tracking systems
> 
> 
> --- Casper Hornstrup <ch...@us...> wrote:
> >It's time to look into bug-tracking systems for the ReactOS 
> project. I 
> >have set up two bug-tracking systems for testing.
> 
> Ok I know.. my little reactos.org system has stalled - but 
> I'm going to give it more attention this week, really! And 
> try and get it into cvs.
> 
> >There is the popular Bugzilla at:
> >and the newer Scarab at:
> 
> My main beef with most bug tracking systems is the way they 
> view the systems against which bugs are logged: as a list of 
> components. The idea behind rosproj (reactos.org system 
> nickname) is that the system is built up of a hierarchy, 
> which more realistically models how ReactOS is structured.
> 
> I really promise to try and get it in cvs this week.
> 
> - Jason
> 
> 
> 
> 
> 
> 
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - your guide to health and wellness 
http://health.yahoo.com

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We
supply the hardware. You get the recognition. Email Us:
ban...@so...
_______________________________________________
reactos-kernel mailing list rea...@li...
https://lists.sourceforge.net/lists/listinfo/reactos-kernel

Re: [ros-general] Re: [ros-kernel] Bug-tracking systems

[KJK::Hyperion <no...@li...>]

At 18.23 05/05/2002, you wrote:
>My main beef with most bug tracking systems is the way they view the 
>systems against which bugs are logged: as a list of components. The idea 
>behind rosproj (reactos.org system nickname) is that the system is built 
>up of a hierarchy, which more realistically models how ReactOS is structured.

Can you give us an anticipation of rosproj?