From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from phicode.de ([136.243.147.240]) by ewsd; Thu Feb  8 03:37:58 EST 2018
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=default; d=phicode.de;
  b=r3vvFH6lF0o+9A90hqtrjOyC2NBb+uDPi2ZRoVqB7F8t5ykZoDNakI2xRrTP0xO48bm/pUiniMqJFwoCnD31nmLHRBzbY/w8yaasjuMH+u3Xm/qW4msx1mWdmRBnIbmtIVdMeaSk4zlY9TLEITuwJKrtp4GLYuECSfu3qYUTRQk=;
  h=Received:Received:Date:From:To:Subject:In-Reply-To:Message-ID:References:User-Agent:MIME-Version:Content-Type;
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=phicode.de; h=date:from:to
	:subject:in-reply-to:message-id:references:mime-version
	:content-type; s=default; bh=7j/rY4RKU28RK++Tzbq1iJ6y+P8=; b=aM7
	l6Ej4gzLKbXy2/h65YLx2MI3sqOSZ+hRglIH+HYv6zR8b0ECBUHWu2bRHL5Clboc
	5+qlE1P+KHo11/QoeJYzCRbJGJFd7gBo7X0ZhoP7IM/8T2klRPXwevzc+vCI6qsY
	3lc/CXF+MTZQD93aeH7uQnLzk5DmWPLRzcHPTDpU=
Received: (qmail 32400 invoked from network); 8 Feb 2018 08:37:43 -0000
Received: from localhost (127.0.0.1)
  by localhost with SMTP; 8 Feb 2018 08:37:43 -0000
Date: Thu, 8 Feb 2018 09:37:42 +0100 (CET)
From: Julius Schmidt <aiju@phicode.de>
To: 9front@9front.org
Subject: Re: [9front] PROPOSAL: New 9front Bug Tracker
In-Reply-To: <0181CC86F20462F489E422A79155DEE5@5ess.inri.net>
Message-ID: <alpine.LNX.2.00.1802080921060.15422@phi>
References: <0181CC86F20462F489E422A79155DEE5@5ess.inri.net>
User-Agent: Alpine 2.00 (LNX 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: realtime-java table 

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
>