Policy on closing bugs
Grzegorz Junka
list1 at gjunka.com
Fri May 24 11:52:31 UTC 2019
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
More information about the freebsd-ports
mailing list