PROPOSAL: New 9front Bug Tracker

PROPOSAL: New 9front Bug Tracker

[sl]

The existing bug tracker sucks.

The following is a list of definitions and features intended to start
a discussion of how to implement a superior replacement.  Please feel
free to comment in this thread.  Once we agree on the spec the new bug
tracker can be implemented.

---

9front Bug Tracker

Definitions

	1.  A bug is a directory whose name briefly describes the bug.

		a.  The bug directory contains a subdirectory mbox
		that contains mdir formatted e-mail files comprising
		the entirety of the discussion thread.

	2.  A bug's status is defined by its location under one of the
	following directories:

		a.  open/

		b.  closed/

		c.  [tba]

	3.  A bug's priority is defined by [tba].

	4.  A bug's assignment (the developer to which the bug is
	assigned) is defined by [tba].

Features

	1.  Create and close bugs by sending an e-mail.

	2.  View bugs, their status, priority, and assignment via
	command line tool, to be included with the default 9front
	system.

		a.  Print a command to open an individual bug's e-mail
		thread in a dedicated nedmail(1).

		b.  Print a command to close an individual bug.

	3.  View bugs, their status, priority, and assignment on the
	web.

	4.  View an individual bug's e-mail thread on the web.

---

We need ideas for Definitions-2-c, Definitions-3, and Definitions-4.

I *think* everything else everyone wanted is covered in the above.

A copy of this proposal has been uploaded to:

	http://9front.org/bugtracker

It will be updated to reflect whatever changes we decide upon, until
consensus is reached.

Now is your chance to tear this proposal apart.

sl

Re: [9front] PROPOSAL: New 9front Bug Tracker

[Lyndon Nerenberg]

> The existing bug tracker sucks.

It would be helpful to know the, say, three most hated things about the 
current regime :-)  Knowing what you're running from can help guide where 
you should be running to.

Re: [9front] PROPOSAL: New 9front Bug Tracker

[Julius Schmidt]

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".

Maybe a simple way to implement most of this is to use a format similar to 
e-mail. Something like

Subject: the front fell off
Assigned-To: cinap_lenrek
Priority: high
State: open
Subsystem: kernel

With 9p you can edit any of this with a text editor.
Via email you can prepend a change to your message, maybe using some 
special token to make it easier to find it between all the e-mail cruft.

Maybe with some minimal vetting/normalisation.
I think we can all agree that having enforced state transitions is an 
un-feature of the more complex bugtrackers :)

State: (new open closed invalid wontfix)
Priority: (newfeature low medium high)

I guess to fit this into a your scheme this would be another file in the 
bug directory.

Anyway just some thoughts.

I know people hate the bureaucracy but I think it's useful to be able to 
search bugs using these fields.

On Wed, 7 Feb 2018, sl@stanleylieber.com wrote:

> The existing bug tracker sucks.
>
> The following is a list of definitions and features intended to start
> a discussion of how to implement a superior replacement.  Please feel
> free to comment in this thread.  Once we agree on the spec the new bug
> tracker can be implemented.
>
> ---
>
> 9front Bug Tracker
>
> Definitions
>
> 	1.  A bug is a directory whose name briefly describes the bug.
>
> 		a.  The bug directory contains a subdirectory mbox
> 		that contains mdir formatted e-mail files comprising
> 		the entirety of the discussion thread.
>
> 	2.  A bug's status is defined by its location under one of the
> 	following directories:
>
> 		a.  open/
>
> 		b.  closed/
>
> 		c.  [tba]
>
> 	3.  A bug's priority is defined by [tba].
>
> 	4.  A bug's assignment (the developer to which the bug is
> 	assigned) is defined by [tba].
>
> Features
>
> 	1.  Create and close bugs by sending an e-mail.
>
> 	2.  View bugs, their status, priority, and assignment via
> 	command line tool, to be included with the default 9front
> 	system.
>
> 		a.  Print a command to open an individual bug's e-mail
> 		thread in a dedicated nedmail(1).
>
> 		b.  Print a command to close an individual bug.
>
> 	3.  View bugs, their status, priority, and assignment on the
> 	web.
>
> 	4.  View an individual bug's e-mail thread on the web.
>
> ---
>
> We need ideas for Definitions-2-c, Definitions-3, and Definitions-4.
>
> I *think* everything else everyone wanted is covered in the above.
>
> A copy of this proposal has been uploaded to:
>
> 	http://9front.org/bugtracker
>
> It will be updated to reflect whatever changes we decide upon, until
> consensus is reached.
>
> Now is your chance to tear this proposal apart.
>
> sl
>

Re: [9front] PROPOSAL: New 9front Bug Tracker

[Kurt H Maier]

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

Re: [9front] PROPOSAL: New 9front Bug Tracker

[Ethan Grammatikidis]

On Thu, Feb 8, 2018, at 9:07 AM, Kurt H Maier wrote:
> 
> 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.

I agree with this point. I hate the priority field when reporting a new 
bug, especially when i'm not involved with the project. These days 
I just ignore it.

-- 
The lyf so short, the craft so long to lerne. -- Chaucer

Re: [9front] PROPOSAL: New 9front Bug Tracker

[Steve Simon]

these are just ideas or discussion, not even suggestions,
use or discard whatever.

states:
    open, closed, rejected, duplicate, awaiting response
issue type
    bug, RFE (request for enhancement), feature request

some well defined space, e.g. an empty place holder file or a dir for:
    issue description
    how to reproduce - for a script, or maybe some c code.
    resolution

Re: [9front] PROPOSAL: New 9front Bug Tracker

[Kurt H Maier]

On Wed, Feb 07, 2018 at 08:34:14PM -0500, sl@stanleylieber.com wrote:
> The existing bug tracker sucks.

To complicate matters, I have recently discovered an existing bug
tracker, written in python, which operates as a mercurial extension,
and stores bugs as maildirs inside the source tree.

It's got a weird license but maybe an email to the author could fix
that.  The license is almost, but not quite, BSD.  

http://www.mrzv.org/software/artemis/

Maybe something from which to draw inspiration.

khm