From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from wopr.sciops.net ([216.126.196.60]) by ewsd; Thu Feb 8 04:07:24 EST 2018 Received: (qmail 87992 invoked by uid 1001); 8 Feb 2018 01:07:20 -0800 Date: Thu, 8 Feb 2018 01:07:20 -0800 From: Kurt H Maier To: 9front@9front.org Subject: Re: [9front] PROPOSAL: New 9front Bug Tracker Message-ID: <20180208090720.GA87033@wopr> Mail-Followup-To: 9front@9front.org References: <0181CC86F20462F489E422A79155DEE5@5ess.inri.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: responsive dependency cloud cache On Thu, Feb 08, 2018 at 09:37:42AM +0100, Julius Schmidt wrote: > I also like having a "new" state. > It singles out bugs that no one has looked at and it's nice for the user > to know that the bug is being acknowledged by someone else. > I'm not proposing a formal process, cinap can of course just close new > bugs if he fixes them immediately, but if a bug is too hard to fix > immediately, someone can verify the issue and mark the bug as "open". I think priority is what you use for state instead of open. You would have new, lowpriority, highpriority, featurerequest, closed. Everything gets moved to closed when it's done, including invalid, notourbug, wontfix, etc. Most bug trackers keep state and priority separate, which makes sense when there's a project manager trying to balance deadlines with budget. We don't have deadlines or budgets, so I'm not sure it's worth creating a two-dimensional data structure to describe bugs. The rest of this email concerns topics I feel less strongly about. Bugs shouldn't be prioritized by submitters anyway; they should be prioritized by someone else. All bugs are high priority for the person reporting the bug. The person fixing the bug should be in charge of deciding how quickly that gets done. So, with Subject coming for free (it's in the email), and state/priority just being top-level directories, all that's left to annotate is owner and subsystem. Just having something that matches /^Subsystem: in any file is probably good enough for the latter. The former can just be subdirectories inside the toplevel directories. That way if I want to find out which low priority open bugs I'm working on that affect the trolling subsystem, grep ^Subsystem:.*troll lowpriority/khm/*/* would get me there. Maybe I'm overthinking this. I'd rather the structure of the directory inherently represent the status of the bugs, rather than having to manually annotate things. I do agree we don't need a state machine. I think it would be easier to not need a state machine if we collapsed state and priority. khm