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
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
Hi Drew,
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.
when the task was fixed and the corresponding cws was created
only OOo 2.0.x and OOo Later targets
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
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,
Hi Andreas
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
Laurent Godard wrote:
Hi Bernard,
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
where are optional parameters
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 :
Frank Schnheit - Sun Microsystems Germany wrote:
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
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
Andrew Jensen wrote:
Question,
I attempted to write a function with the following declaration:
function findCodeVal( RegDSName as String, _
TableName as String, _
SrchColName as String, _
SrchFor as variant, _
Bonjour Andrew Douglas Pitonyak
Message du 2006-01-02 16:30:
Andrew Jensen wrote:
I attempted to write a function with the following declaration:
function findCodeVal( RegDSName as String, _
TableName as String, _
SrchColName as String, _
Hi Bernard,
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
where are optional parameters located in the source
Well, I have done a quick test with the information about order of
testing,.that does cause the problem. But it still appears that the type
of parameter plays a role. It seems that as long as the order, relative
to type is maintained it works. I will take time this evening and try to
pin this
Question,
I attempted to write a function with the following declaration:
function findCodeVal( RegDSName as String, _
TableName as String, _
SrchColName as String, _
SrchFor as variant, _
RetColName as
15 matches
Mail list logo