Policy on closing bugs

[Grzegorz Junka]

On 24/05/2019 12:48, Kubilay Kocak wrote:
> On 24/05/2019 10:45 pm, Grzegorz Junka wrote:
>>
>> On 24/05/2019 12:34, Kubilay Kocak wrote:
>>> On 24/05/2019 9:52 pm, Grzegorz Junka wrote:
>>>>
>>>> On 24/05/2019 11:30, Grzegorz Junka wrote:
>>>>>
>>>>> On 24/05/2019 11:12, Kubilay Kocak wrote:
>>>>>> On 24/05/2019 8:07 pm, Grzegorz Junka wrote:
>>>>>>> Hey,
>>>>>>>
>>>>>>> Is there any policy/document when a bug can be closed? For 
>>>>>>> example, is it OK to close a bug that is fixed upstream but not 
>>>>>>> yet in ports?
>>>>>>>
>>>>>>> Thanks
>>>>>>> GrzegorzJ
>>>>>>>
>>>>>>
>>>>>> Hi Grzegorz,
>>>>>>
>>>>>> Bugs are closed after they are "resolved". Resolved means a 
>>>>>> resolution has "occurred", but more precisely, the "thing 
>>>>>> reported" has been resolved. Resolved doesn't necessary mean 
>>>>>> "fixed" (see below)
>>>>>>
>>>>>> What resolution is appropriate/set depends on the context of the 
>>>>>> issue, usually the specific nature of the request/proposal. Is 
>>>>>> there a specific bug you're referring to? I can speak to that 
>>>>>> case specifically if so.
>>>>>>
>>>>>> For example however, if the bug was a "bug report for the 
>>>>>> port/package", fixed upstream hasn't fixed the port, so not 
>>>>>> usually, no, that wouldn't be considered sufficient to be 
>>>>>> "resolved" and closed.
>>>>>>
>>>>>> Usually commits upstream are backported to the ports, and they 
>>>>>> are closed when those are committed.
>>>>>>
>>>>>> There can't be policies for this perse, as its completely 
>>>>>> context/request dependent.
>>>>>>
>>>>>> Resolutions can take place either by way of:
>>>>>>
>>>>>> 1) A change is made: a commit, usually, but could be a wiki 
>>>>>> update, or a DNS update for infrastructure changes, etc.
>>>>>> 2) One of the 'non-change' resolutions: not accepted, unable to 
>>>>>> reproduce, feedback timeout, etc
>>>>>>
>>>>>> Nothing about the above is special or different than most other 
>>>>>> issue trackers (generally speaking).
>>>>>>
>>>>>> Regarding states, we have New, Open, In Progress, Closed
>>>>>>
>>>>>> New: Not touched/Untriaged
>>>>>> Open: Initially Triaged (classified)
>>>>>> In Progress: Has a real (person) Assignee, action has started
>>>>>> Closed: Change(s) Made, OR "Non-Change" resolution set.
>>>>>>
>>>>>> There's nothing special/different about these either, except that 
>>>>>> we like to have a real person assigned before in progress, and 
>>>>>> before close.
>>>>>>
>>>>>> Happy to answer any more questions regarding issue tracking, etc 
>>>>>> anytime
>>>>>>
>>>>>
>>>>> Hi Kubilay,
>>>>>
>>>>> Thank you for a detailed response. Yes, this is related to a 
>>>>> particular defect. I didn't mention it because I didn't want to be 
>>>>> picky and seen as causing troubles :) Also wasn't sure what's OK 
>>>>> and what's not. Here is the defect:
>>>>>
>>>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238086
>>>>>
>>>>> I appreciate Yuri's contributions to the community and my 
>>>>> intention isn't to bring this up for judgment. Even though as a 
>>>>> FreeBSD user I might feel a bit ignored and shuffled under the 
>>>>> carpet after the defect has been closed, my intention was more to 
>>>>> find out if maybe a new state "Postponed" could be added for a 
>>>>> defect in a state like this one?
>>>>>
>>>>
>>>> A very similar story with:
>>>>
>>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238088
>>>>
>>>> It's not scheduled to be removed per se yet. The removal is under 
>>>> discussion with no clear path agreed as far as I know. I understand 
>>>> that a maintainer doesn't want to spend time working on a port that 
>>>> will likely undergo significant changes or removal but is closing 
>>>> the defect the right thing to do? And again, a "Postponed" state 
>>>> seems to me to be more appropriate?
>>>>
>>>> GrzegorzJ
>>>>
>>>>
>>>
>>> The better resolution for this is again probably: Not Accepted (as 
>>> WONTFIX), though I can understand why "Overcome by Events" was 
>>> selected (wont be fixed *because* of a separate overruling issue).
>>>
>>> From a reading of the associated bug (215036), it reads fairly 
>>> clearly that the 0.x branch is not supported (security wise, in 
>>> particular), and no further work will be done on it. That the port 
>>> has been deprecated (DEPRECATED/EXPIRY_DATE) is evidence of that 
>>> decision.
>>>
>>
>> Agreed in principle, but the port hasn't yet been marked as 
>> DEPRECATED/EXPIRATION_DATE. Unless it was done in the last few days 
>> (I synced my ports 18 May).
>>
>>
>> _______________________________________________
>> freebsd-ports at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
>> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"
>
> Indeed it has: https://svnweb.freebsd.org/changeset/ports/502453
>
> The same day, 6 minutes after your comment about it not having an 
> EXPIRATION_DATE :)
>

All right, I did see the commit but I thought the commit message is the 
actual change. I should have tried to dig deeper. Sorry about that. I 
guess this one is sorted then :)