OK, I've got a sandbox set up here and may be able to help with Mac OSX
& other bug triage. Mostly would only be able to confirm issues, not
much programming experience.
I don't have much available time, but would still like to be able to
try.
I'm running 1.8.9-12 on Mac OSX 10.3.4. I'm still on
> >>>
> > Would you prefer we start with oldest or newest unconfirmed bugs. Maybe
> > each of us should start from different end.
>
> I don't have a preference. Just being able to close out bugs that
> are no longer a factor, or bugs that cannot be reproduced... and pushing
> back bugs that don't
Guys, some issue have come up in may day job that is going to have me tied
up. Hope to assist at a later date.
Keep up the good work,
Steve
___
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
"Englisch, Volker (NIH/NCI)" <[EMAIL PROTECTED]> writes:
>> Uhh... What makes you think that these two bugs are the same? IMHO
>> these two are _not_ the same bug. 88517 is about cut-and-paste losing
>> transaction information, whereas 92484 is about bulk moves of
>> transactions. They are cert
> Uhh... What makes you think that these two bugs are the same? IMHO
> these two are _not_ the same bug. 88517 is about cut-and-paste losing
> transaction information, whereas 92484 is about bulk moves of
> transactions. They are certainly different in my mind. Why do you
> consider them the sa
Title: Re: Bug Triage
Derek,
I was wondering how we should be handling duplicate bugs that we identify. I've found Bug 88517 and 92484 being identical (assigned to two different developers). Should we contact the developers to have them review and mark these as duplicates themselv
Uhh... What makes you think that these two bugs are the same? IMHO
these two are _not_ the same bug. 88517 is about cut-and-paste losing
transaction information, whereas 92484 is about bulk moves of
transactions. They are certainly different in my mind. Why do you
consider them the same?
When
"Steve Romanow" <[EMAIL PROTECTED]> writes:
> Ok, Why dont you start with oldest, I'll start with newest. I am having
> some difficulty with the machine I was going to use as my sandbox, but I
> should be able to start shortly (within a week or so).
FYI (this is probably obvious, but...) You mi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, June 23, 2004 10:34 am, Englisch, Volker (NIH/NCI) said:
>> >>>
>> > Would you prefer we start with oldest or newest unconfirmed bugs.
>> Maybe
>> > each of us should start from different end.
>>
>> I don't have a preference. Just being able t
"Englisch, Volker (NIH/NCI)" <[EMAIL PROTECTED]> writes:
> I was thinking to look at the oldest bugs first hoping that most of those
> could be closed out because they can not be reproduced in the newer
> versions.
True.
> Maybe the easiest for now would be to one of us start from the top while
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, June 23, 2004 9:59 am, Derek Atkins said:
> If I can go to a bug and easily reproduce it, I can (generally) easily
> fix it. Sometimes the reproduction part is the most challenging
> aspect!
>
> -derek
>
I agree, when users in my day job give
"Steve Romanow" <[EMAIL PROTECTED]> writes:
>>>
> Would you prefer we start with oldest or newest unconfirmed bugs. Maybe
> each of us should start from different end.
I don't have a preference. Just being able to close out bugs that
are no longer a factor, or bugs that cannot be reproduced...
On Wed, June 23, 2004 9:29 am, Derek Atkins said:
> Right now we don't have a good process in place for marking bugs
> as "reproducible". We do use the NEEDINFO to mark a bug as,
> well, need more info. :)
>
> I suppose that, once you confirm a bug you can change it from UNCO ->
> NEW to confirm i
13 matches
Mail list logo
