Policy on closing bugs

[Grzegorz Junka]

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).