New metabugs

[hatky]

--- Mike Hearn <m.hearn at signal.qinetiq.com> wrote:
> On Fri, 2003-05-02 at 08:47, hatky wrote:
> > Ok, with you permission I like to get this subject
> > changed a bit to clearing bugzilla.
> > 
> > I noticed there are plenty of bugs and little
> activity
> > on any of then many of them look outdated.
> 
> Yeah, this is a problem for all bugzillas. About a
> month or two ago a
> few of us went through and cleaned some out. Needs
> doing more often
> really though.
> 
> > So I would like Step One to be getting all the
> bugs
> > that there last comment was before 6 months or
> more
> > commented as please test it again or we will close
> it
> > in the next 30.
> 
> This sounds like a good idea. We've done it before,
> but it takes time to
> track them all.
Can't we do automaticly? I am pretty sure there can be
an sql select that can get that then we need to feel a
form...
I realy think I could have a php file that does that
if I hade the table stracture ...
Then we can run it dayly as a cron job and no bug will
be really left out to die (I am only talking about the
traking prosses here)
> 
> > I really hope you agree with me about that becouse
> > with so many open bug I think most developer DO
> NOT
> > want to trak the bugzilla any more...
> 
> Well, I know I mostly go by the wine-bugs mailing
> list, but it does make
> bugs easy to forget about. Remember though that
> often people just don't
> know the answer.....
I undertend that but if you know of a bug that says it
gets into a race condition and you see in wine-cvs
that a patch aginst race conditions have been aplied
even if you are not sure that that the same race
condition asking the user to test it again can be
helpfool, better then leaving a bug with the last test
some where on 2001 or earlier with no other
comments...
> 
> > Secound Step I would want to do is getting the
> bugs
> > into some categories so it will be easy for
> developer
> > to track the bugs that intrest them 
> 
> This idea I'm not so sure about. If somebody is
> interested in working on
> games, then they can fire up games they actually own
> and start fixing
> bugs. 
That why I rather have big meta bugs and then the
errors in them as sub bugs that way:
1.If you are trying to fix problem X you can locate a
few testcases that would help you ensure you solved it
right.
2.If you fix problem y we can tell to all users with
games that have problem y we are a step closer to
running there game (game or app or any other program)
3.You can see with function that is still missing is
most needed, I was thinking it would probebly be
usefull for people like workers of codewavers but
would you rather fix a problem with one program or a
problem you know make 15 programs not work? I
personaly sould like to sort my prioritys on the
problems that block the most programs (I am making
sence right?)
> Unfortunately Wine is not yet at the stage
> where people find it
> hard to locate bugs :(
That would mean we could drop bugzilla all toghter (I
am nither aginst nor for) but as long as it's up I
think we sould maintain the bugs in it as it was ment
to be.
> 
> > btw just to understend this is a meta bug of
> getting
> > game x to work and under it all the uniplemented
> > or/and broken stuff ok?
> 
> I think these things are better done when somebody
> with drive says "I'm
> going to make game X work" and then goes ahead and
> solves them all - the
> chances of finding 2 or 3 people all with that game
> and all with that
> drive/level of skill is fairly rare, they all work
> on different games.
I was thinking about bugzilla as being for both users
and developers so when that time comes where deleoper1
has all the program he owns working (hopfully soon ;-)
optimistic ha?)
he could help fixing programs he does not own, that a
user reportes an with bugzilla getting the developer
to fix and the user to test.... (Besides why sould a
developer waist his/her time testing every feather of
a big program? We can let users do it and gain a
little more programming time)
> 
> > The last step (and an importent one) would be to
> try
> > keep the traking a live by insreting both
> developers
> > and users to look at them and keep updating them.
> 
> If nobody knows what causes a bug, or the bug is
> "implement feature X"
> then no amount of tracking will get the work done
> quicker. It basically
> boils down to a terminal lack of manpower.
I do agree that if no one know why that happened then
it is a problem but even so it sould be tested again
after a few months for a by mistake fix :) 

It is know we lack in man power thats they I say we
use bigzilla get let users do testing insted of
developers, and the more bugs will be solved the more
users will join and the more bugs will be up to date
the more users will use bugzilla and the more users
wine has the more news it will get and more new
developers that will solve more bugs.
> 
> > Do you agree with anything I said so far or am I
> just
> > talking newbee crap?
> 
> It's good you're thinking about these things, but
> experience with
> bugzillas tells me that especially for a project
> like Wine, while it can
> be very useful to track odd bugs/regressions etc,
> for more general
> things it's not so useful.
Do you want to make a defintion of what bugs we sould
open and track and what sould not get into bugzilla at
all?
> 
> thanks -mike
> 
> -- 
> Mike Hearn <m.hearn at signal.qinetiq.com>
> QinetiQ - Malvern Technology Center
> 
Hatky.

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com