From: Kurt H Maier <khm@sciops.net>
To: 9front@9front.org
Subject: Re: [9front] PROPOSAL: New 9front Bug Tracker
Date: Thu, 8 Feb 2018 01:07:20 -0800 [thread overview]
Message-ID: <20180208090720.GA87033@wopr> (raw)
In-Reply-To: <alpine.LNX.2.00.1802080921060.15422@phi>
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
next prev parent reply other threads:[~2018-02-08 9:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-08 1:34 sl
2018-02-08 2:08 ` [9front] " Lyndon Nerenberg
2018-02-08 8:37 ` Julius Schmidt
2018-02-08 9:07 ` Kurt H Maier [this message]
2018-02-08 16:54 ` Ethan Grammatikidis
2018-02-08 23:23 ` Steve Simon
2018-02-08 23:56 ` Kurt H Maier
2018-02-08 2:55 sl
2018-02-09 3:01 sl
2018-02-09 3:15 sl
2018-02-09 3:21 sl
2018-02-09 3:31 sl
2018-02-09 5:11 ` Eli Cohen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180208090720.GA87033@wopr \
--to=khm@sciops.net \
--cc=9front@9front.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).