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

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

[sl]

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

When 9front started it was hosted at Google Code because they offered
mercurial and we needed a reliable place to host code.  Google Code
came with a free bug tracker, so people used it.

When Google Code went away we lost that.  Eventually cinap complained
that we no longer had a bug tracker.  After some discussion we settled
on the following design:

	A bug is a directory named for a brief description of the bug
	that contains a file readme which includes the original bug
	report plus whatever comments were later added by 9front
	developers.  The bug's status is defined by its location
	within one of two directories: open/ or closed/.

This worked okay, but in practice most of the bugs never had any
commentary added to them.  Bugs might not even get closed after the
fix was committed.  Bascially, I was the only one managing the bug
reporting system.  Most of it manually.

At some point we started forwarding bug reports to a separate
9front-bugs mailing list.

At some point we engineereed a web interface.

Most of these add-ons were implemented in an incomplete, or otherwise
unsatisfactory fashion.  Nobody likes the web interface.  There is a
lot of confusion amongst users as to how to file a bug, how to reply
to a bug report, where to discuss the bug once it has been filed, how
to figure out what is going on.  People were replying directly to the
9front-bugs list, which was never intended (the capability to do so
was an oversight on my part).  People were sending updates to
9front-bugs-open, which created a new, separate bug for every mail
message sent to it.

My proposal aims to address all these problems.

For our purposes, there are two main purposes for the bug tracker,
without which there is no reason for it to exist:

	1.  Create a succinct summary and central repository of bug
	information for cinap and other developers to glance at.

	2.  Avoid duplication of random bug reports and duplication of
	work.

If we don't fulfill these then we're wasting our time.

sl

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

[sl]

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


> So, with Subject coming for free (it's in the email), and state/priority
> just being top-level directories,

This seems good.


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

That seems fine.  Or, should we just have a file subsystem that is
just a one line (or one word) description of the subsystem.  That
would be very easy to create, find, and manipulate.


> The former can just be
> subdirectories inside the toplevel directories.

This is probably fine, too, but do we really even need to assign bugs
to individuals?  In our context, what are the benefits vs the
administrative overhead?

sl

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

[sl]

> 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

FQA 2.4.1 covers this, but perhaps it could be made more explicit as a
template, so users can just fill in the blanks.

sl

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

[sl]

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

One of the reasons I am interested in rolling a custom bug tracker is
because I like the idea of using the 9front system to maintain and
host the 9front system.  Every outside facility is something we don't
control and will probably have to replace later (in this case, if we
ever get rid of python, which everyone says we want to do).  In my
opinion, alien software (as in, not Plan 9 native) should always be
considered a last resort.  Otherwise, why are we doing any of this at
all?

That said, we could just use this.

sl

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

[sl]

The draft proposal has been updated:

	http://9front.org/bugtracker

Diff follows:

src/bugtracker:9,30 - /n/ewsd/usr/sl/www/werc/sites/9front.org/bugtracker:9,39
  		the entirety of the discussion thread.
  
  	2.  A bug's status is defined by its location under one of the
- 	following directories:
+ 	following top directories:
  
- 		a.  open/
+ 		a.  new/
  
  		b.  closed/
  
  		c.  [tba]
  
- 	3.  A bug's priority is defined by [tba].
+ 	3.  A bug's priority is defined by its location under one of
+ 	the top directories listed in Definitions-2.
  
  	4.  A bug's assignment (the developer to which the bug is
  	assigned) is defined by [tba].
  
+ 	5.  The subsystem to which a bug applies is defined by the
+ 	contents of a file subsystem under the bug's top directory.
+ 	Valid subsystems include:
+ 
+ 		a.  [tba]
+ 
  Features
  
- 	1.  Create and close bugs by sending an e-mail.
+ 	1.  Create and close bugs by sending an e-mail.  In both cases
+ 	the e-mail is forwarded to the regular 9front@9front.org
+ 	mailing list.
  
  	2.  View bugs, their status, priority, and assignment via
  	command line tool, to be included with the default 9front

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

[Eli Cohen]

i don't think bug assignment matters that much. everyone does it, but
the point of these things is to document bugs and acknowledge repair

On Thu, Feb 8, 2018 at 7:31 PM,  <sl@stanleylieber.com> wrote:
> The draft proposal has been updated:
>
>         http://9front.org/bugtracker
>
> Diff follows:
>
> src/bugtracker:9,30 - /n/ewsd/usr/sl/www/werc/sites/9front.org/bugtracker:9,39
>                 the entirety of the discussion thread.
>
>         2.  A bug's status is defined by its location under one of the
> -       following directories:
> +       following top directories:
>
> -               a.  open/
> +               a.  new/
>
>                 b.  closed/
>
>                 c.  [tba]
>
> -       3.  A bug's priority is defined by [tba].
> +       3.  A bug's priority is defined by its location under one of
> +       the top directories listed in Definitions-2.
>
>         4.  A bug's assignment (the developer to which the bug is
>         assigned) is defined by [tba].
>
> +       5.  The subsystem to which a bug applies is defined by the
> +       contents of a file subsystem under the bug's top directory.
> +       Valid subsystems include:
> +
> +               a.  [tba]
> +
>   Features
>
> -       1.  Create and close bugs by sending an e-mail.
> +       1.  Create and close bugs by sending an e-mail.  In both cases
> +       the e-mail is forwarded to the regular 9front@9front.org
> +       mailing list.
>
>         2.  View bugs, their status, priority, and assignment via
>         command line tool, to be included with the default 9front



-- 
http://echoline.org