[MPlayer-dev-eng] bugzilla states

Michael Niedermayer michaelni at gmx.at
Wed Jul 14 23:28:05 CEST 2004


Hi

On Wednesday 14 July 2004 18:16, Diego Biurrun wrote:
> On Wed, Jul 14, 2004 at 03:20:54PM +0200, Michael Niedermayer wrote:
> > On Wednesday 14 July 2004 11:45, Diego Biurrun wrote:
> > > Jan Knutar writes:
> > > > > http://bugzilla.mplayerhq.hu/bug_status.html
> > > >
> > > > I think "Verified" is very confusing and non-intuitive in this
> > > > definition.
> > > >
> > > > If verified is to be used as "Someone checked the fix and it's ok",
> > > > couldn't it be named something different?
> > > >
> > > > Intuitively to me, "VERIFIED" has the oposite meaning of
> > > > "UNCONFIRMED", and would be the next natural step in the bug's
> > > > lifecycle from unconfirmed.
> > >
> > > The opposite of UNCONFIRMED is confirmed, plain and simple.  It's just
> > > a matter of getting used to the semantics of the different words in
> > > the Bugzilla context.  If somebody acknowledges that a bug is real it
> > > is CONFIRMED, if somebody checks a resolution and agrees, then the
> > > resolution is VERIFIED.
> >
> > UNCONFIRMED->CONFIRMED->... is fine, but UNCONFIRMED->NEW and VERIFIED is
> > very confussing, NEW should be renamed to CONFIRMED and VERIFIED should
> > be renamed to FIXED&VERIFIED IMHO, or some other choice of names is fine
> > too, just the default is not IMHO
>
> VERIFIED can not only be FIXED&VERIFIED but any resolution, so you have
>
> VERIFIED FIXED
> VERIFIED WORKSFORME
> VERIFIED INVALID
> VERIFIED DUPLICATE
ugh ...
and VERIFIED VERIFIED FIXED
VERIFIED REOPENED
VERIFIED NEW
...

the problem here, u can verify everything, FIXED probably has some special 
need for verification, IMO the others dont, if we allow them to be verified 
its difficult to justify why other states cant be verified
furthermore one could argue that verificaion can be done multiple times, and 
thus should be an integer, but thats not too usefull in practice i guess

>
> etc
>
> > btw, why are u so strongly against changing the names? i cant see any
> > disadvantage in changing them
>
> I'm not fundamentally or strongly opposed to changing those names, but I
> think things are being approached from the wrong angle.  Really, I mean no
> offense, but IMNSHO people should first learn to use the software and then
> come up with changes.  So far I have only seen comments from people with
> little or no Bugzilla experience and some don't even appear to have read
>
> http://bugzilla.mplayerhq.hu/bug_status.html
i did read this before sending my first mail, and state names which need the 
user/developer to read&learn such text are not well choosen, there is no 
doubt that everyone can learn 10 meaningless words and remember what they 
mean, but its much better if the names make sense without reading the docs
its similar to replacing variable names with single letters and then adding a 
comment at the top of the function which explains which single letter means 
what, its no problem to figure out what the code does its just more work for 
everyone

>
> I'm quite used to Bugzilla and I find it neither counterintuitive nor
> particularly hard to use.  It IS tailored to the way Mozilla is developed,
> though (and I have my background there), so we will most surely need to
> make some changes to adapt it to our needs.  I'm just afraid the changes
> suggested so far are partially the result of not being used to the way
> Bugzilla works.  Bugzilla takes some time to get used to, I'm afraid there
> is no way around this.
then i vote against bugzilla
we should use a system which can be used without investing alot of time to 
learn it, after all we want a user to be able to report a bug and participate 
in the bugfixing without needing to spend maybe more time learing how to use 
the bugtracking system then he spends finding a bug and fixing it

[...]
-- 
Michael
level[i]= get_vlc(); i+=get_vlc();		(violates patent EP0266049)
median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]);	(violates patent #5,905,535)
buf[i]= qp - buf[i-1];				(violates patent #?)
for more examples, see http://mplayerhq.hu/~michael/patent.html
stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en




More information about the MPlayer-dev-eng mailing list