Policy on closing bugs

[Kubilay Kocak]

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