[webkit-dev] Bug life cycle

Joost de Valk webkit-dev at joostdevalk.nl
Mon Nov 14 00:34:35 PST 2005


On Nov 14, 2005, at 8:01 AM, Maciej Stachowiak wrote:

>
> On Nov 12, 2005, at 6:51 AM, Joost de Valk wrote:
>
>> Hi all,
>>
>> today, while talking on #webkit, i got two questions which both  
>> should be answered in the bug life cycle document on the WebKit  
>> page as well, in my humble opinion. To be able to do that, i'd  
>> like to get some consensus on them.
>>
>> The first one, brought up by Alexey Proskuryakov (ap), is this:  
>> when a bug can't be reproduced anymore but has been confirmed at  
>> one point in time, what to do with it? My answer for this would be  
>> to close it as "WORKSFORME" and not as "FIXED", since you don't  
>> know what fixed it. Ideally we would create a new resolution for  
>> this, something like "FIXED WITHOUT SOLUTION" or something like  
>> that, have you people perhaps got any thoughts on this?
>
> How about "PRESUMED FIXED". I also wish we could get the  
> ALLCAPSSINGLEWORD style out of the resolutions. Not sure how hard  
> this is to do without hacking the database. Something that is  
> believed fixed by an unknown change is indeed different than  
> something that couldn't be reproduced at all, although "WORKSFORME"  
> arguably could cover both bases. "PRESUMED FIXED" would indicate to  
> the verifier that they must verify with a more recent version, and  
> would indicate to integrators that if they want to ship the fix on  
> a branch version, they have to hunt for it.
>

This is fine by me, getting rid of the all caps would be great, but i  
don't know if we break any external apps by doing that?

>> The second one: a bug that is fixed goes to verified, and to  
>> closed when it's in an Apple release of WebKit. However, as Mitz  
>> Pettel pointed out, we have bugs as well which are regressions  
>> from previous versions, these will, when fixed, never get into a  
>> release. I propose that we close them anyhow, since they should  
>> have a keyword which indicates that it was a regression.
>
> Eventually a release ships which would have had the regression but  
> also had the fix. But it's true that it would be unclear how to  
> test for that release. In the apple-internal bug tracker, there is  
> no clusing step separate from verifying - a bug that has been  
> verified ends up in state closed. So I think from that perspective  
> we are not too concerned about the distinction.

We roughly have two options here, either we close bugs that were  
regressions immediatly on verification, or we don't close them at  
all. Maybe, just maybe, the latter one would be even better. Maybe we  
should also get rid of the "CLOSED" state? Anyhow, for all of the  
above to mean anything, we should know if it is at all possible to  
add or change a resolution. Perhaps someone can shed some light on  
that matter?

Regards,
Joost
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2424 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/webkit-dev/attachments/20051114/204b63ee/smime.bin


More information about the webkit-dev mailing list