Optional Parameters in Starbasic function call

Bonjour Andreas Bregas
Message du 2006-01-03 15:05:
> Hi,
> 
>>> The bug was reported in IZ 30500. In versions
1.1.x and 2.0.1 it is 
>>> still not corrected and not even documented, so
it should not have 
>>> status RESOLVED and FIXED.
>>
>>
>> perhraps reopen the bug and mark it as regression
in keywords
> 
> 
> no, please don't. The status is correct as this task is
really fixed
> on my cws ab19. But both the cws and the task are
targeted OOo Later
> and the cws is not integrated yet. So no master
containing the fix
> is available. Nevertheless it is Resolved/Fixed and of
course it's
> no regression either.
> 

I can't understand this. If it's fixed it should be
integrated ASAP, why 
keep it OOo Later ? It was fixed in August 2005, and could
have been 
integrated in 2.0.1.
I queried IssueZilla for : RESOLVED and FIXED and OOo Later
and Creation 
date between 2005-01-01 and now. Result : 75 issues ! What
are you 
developers waiting for ? More duplicate reports ? More
disappointed users ?

    Bernard


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeapi.openoffice.org
For additional commands, e-mail: dev-helpapi.openoffice.org

Hi Bernard,

> I can't understand this. If it's fixed it should be
integrated ASAP, why 
> keep it OOo Later ? It was fixed in August 2005, and
could have been 
> integrated in 2.0.1.
> I queried IssueZilla for : RESOLVED and FIXED and OOo
Later and Creation 
> date between 2005-01-01 and now. Result : 75 issues !
What are you 
> developers waiting for ? More duplicate reports ? More
disappointed users ?

I can't talk about the concrete issue here, but let me say a
general
word about those other 74 ...
Every bug fix has the potential of a regression. While we
all try our
best to avoid this, reality shows that a certain percentage
of bug fixes
causes a new bug. Because of this, there are restrictions on
what kind
(and how many) fixes we put into the "maintainance
releases" such as
2.0.x. Those releases are expected to improve the product,
not to
decrease its quality. We simply do not want to take the risk
associated
with all the bug fixes we could have (and potentially, we
*could* have
much more than those 75, if we wanted to), at least not for
2.0.x.

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer        
frank.schoenheitsun.com -
- Sun Microsystems                      http://www.sun.com/star
office -
- OpenOffice.org Database                   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - -

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeapi.openoffice.org
For additional commands, e-mail: dev-helpapi.openoffice.org

Hi Andrew,

> But Bernard has a very valid point also. ...

I didn't question this, but wrote

>>I can't talk about the concrete issue here, but let
me say a general
>>word about those other 74 ...

Honestly, I simple didn't follow the whole thread, only
Bernard's last
mail sprung to my attention because of this statement about
resolved-lated issue.

I absolutely believe that there are resolved-later issues
which better
go into some 2.0.x, but I didn't even attempt to judge this
concrete case 

> If I might make a suggestion, when weighing the
risk/benefit factors -
> length of time that the issue has been open be taken
into account.
> In a situation like this if a fix is deemed to risky
for release - at
> least try and see if a reasonable target can be set.
The ambiguity of
> OOLater for an 18 month fix is a bit much.

My personal opinion here (again without having judged the
concrete case)
is that if an issue is annoying people for that long time,
and this is
shown by votes, constant complaints, whatever, it should get
some points
on the pro-include-in-2.0.x side - it might be considered a
"customer
escalation" then .

> Final point, they are called maintanence releases
because they
> incorporate fixes to known defects.

Well, but that definition is to broad ... The number of
known defects
(just query IZ) is much higher than we will fixed for even
"OOo Much Later".

Thanks & Ciao
Frank

-- 
- Frank Schönheit, Software Engineer        
frank.schoenheitsun.com -
- Sun Microsystems                      http://www.sun.com/star
office -
- OpenOffice.org Database                   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - -

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeapi.openoffice.org
For additional commands, e-mail: dev-helpapi.openoffice.org

Hi Andrew,


> I would think that if the defect merited the allocation
of the developrs
> time to implement the fix it merits the time to be
tested to the extent
> needed for release. The fact will remain that only the
development
> staff involved can judge what that effort really is.
> 
> Look at it this way, was it really the best allocation
of the developers
> time - a very tight resource, I hae no doubt, if the
resoures to do what
> is necessary to get the fruits of their effort out to
the users is not
> also made available?

I could imagine various reason why a bug is fixed though
it's targeted
for "Later", amongst them
- "it was fun, and I still needed my weekly fun on
Friday" 
- while investigating how serious this issue is, I
immediately found a
  fix, and it would have been waste to not check it in
- I stumbled upon this during completely unrelated work, and
fixed it
  by passing

All of this may justify that the fix is still *made*, but
not yet that
it's include in 2.0.x.

> But - Speaking of useful allocation of time, - enough
of this subject
> for me perhaps. Just slip on into
> Issuzilla and target it for 2.0.3..no one will notice
that you did it...
> 


I doubt that. You don't imagine how strict 2.0.x targets can
be handled
by some people ;)

(not to mention that I still didn't look at the issue which
caused all
this, still just dicussing the more general aspects)

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer        
frank.schoenheitsun.com -
- Sun Microsystems                      http://www.sun.com/star
office -
- OpenOffice.org Database                   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - -

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeapi.openoffice.org
For additional commands, e-mail: dev-helpapi.openoffice.org

Andrew Jensen wrote:

> Frank I understand your point about not releasing every
fix possible 
> in every maintenance release as a form
> of risk management. I also did a quick query off
IssueZilla finding 
> 108 defects marked for target of 2.0.2
> that have been changed to resolved in the last 369 days
( excluding, 
> as best I could, those dealing solely
> with documentation [203 if I query everything]). Also 9
enhancements? 
> So, of course you guys aren't just loafing.
> Further, I suppose it is reasonable that a person
should make note
> of the fact that a defect marked as resolved but not
given a target 
> milestone is not in the queue to be
> released.
>
Some releases have a very specific reason or focus. Version
2.0 was 
released knowing full well that certain issues still existed
so they 
made the release with plans on what to fix immediatly,
nothing more and 
nothing less. You fix these and then we release. If you are
a tester and 
you are testing something else, then you are probably in
trouble.

Now, that said.... I wonder what would not have been
released if they 
had taken the time to verify some of the other stuff...

-- 
Andrew Pitonyak
My Macro Document: http://www.pi
tonyak.org/AndrewMacro.odt
My Book: http://w
ww.hentzenwerke.com/catalog/oome.htm
Info:  http://www.pitonyak.or
g/oo.php
See Also: http://documentation.openoffice.org/HOW_TO/index.html

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeapi.openoffice.org
For additional commands, e-mail: dev-helpapi.openoffice.org