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@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
