Date: Fri, 24 May 2019 22:48:57 +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: <20a4ec02-3c58-588e-dfb8-d5a4c29fe04b@FreeBSD.org> In-Reply-To: <85bd9ecf-6b66-324f-78eb-3170cb037248@gjunka.com> References: <2d6b1503-8ecd-6313-525b-e9f104fcb7f6@gjunka.com> <3ca47a0a-e8ae-e36f-c499-b26f8997e55c@FreeBSD.org> <341fe47b-1104-3050-f85b-504be0460c48@gjunka.com> <b182523b-7ef1-06a4-cee0-809311fcb39a@gjunka.com> <3f2d8d56-c223-596e-caaf-d17d6a0decd5@FreeBSD.org> <85bd9ecf-6b66-324f-78eb-3170cb037248@gjunka.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@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 :)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20a4ec02-3c58-588e-dfb8-d5a4c29fe04b>