Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 24 May 2019 21:12:29 +1000
From:      Kubilay Kocak <koobs@FreeBSD.org>
To:        Grzegorz Junka <list1@gjunka.com>, freebsd-ports@freebsd.org
Subject:   Re: Policy on closing bugs
Message-ID:  <3ca47a0a-e8ae-e36f-c499-b26f8997e55c@FreeBSD.org>
In-Reply-To: <2d6b1503-8ecd-6313-525b-e9f104fcb7f6@gjunka.com>
References:  <2d6b1503-8ecd-6313-525b-e9f104fcb7f6@gjunka.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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

--
Regards,

Kubilay
Bugmeister



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3ca47a0a-e8ae-e36f-c499-b26f8997e55c>