Discussion:
interested in issue tracker dev
a***@gmail.com
2012-01-12 17:34:09 UTC
Permalink
I might be interested in trying to help write one such suckless issue tracker as requested on the webpage.

I just want to ask;
What set of features are a must for you?

Thanks,
cheers.
Anselm R Garbe
2012-01-12 18:06:17 UTC
Permalink
Post by a***@gmail.com
I might be interested in trying to help write one such suckless issue tracker as requested on the webpage.
I just want to ask;
What set of features are a must for you?
Oh what a relief someone wants to volunteer on this idea.

One of the most important things of such a tracker is decent mail
integration in my opinion (as most trackers that have evolved in the
OSS space recently suck very much when it comes to mail integration).

One aspect of this tracker could be to start with a proper mail
archiving system and then writing the web stuff on top. This would
allow proper querying. The mail archiving could be based on a
repository storage (hg or git) instead of some poor database based
system.

All the controlling could be done mail based (similarly to mlmmj perhaps).

What do you think?

Cheers,
Anselm
Bjartur Thorlacius
2012-01-12 18:58:16 UTC
Permalink
What's wrong with GNATS?
Anselm R Garbe
2012-01-12 19:44:51 UTC
Permalink
Post by Bjartur Thorlacius
What's wrong with GNATS?
Nearly everything. GNU, 50kSLOC, etc.

Cheers,
Anselm
markus schnalke
2012-01-12 21:32:53 UTC
Permalink
Post by Anselm R Garbe
Post by a***@gmail.com
I might be interested in trying to help write one such suckless
issue tracker as requested on the webpage.
I just want to ask;
What set of features are a must for you?
Oh what a relief someone wants to volunteer on this idea.
One of the most important things of such a tracker is decent mail
integration in my opinion (as most trackers that have evolved in the
OSS space recently suck very much when it comes to mail integration).
What about debbugs? Haven't set it up yet, but used it within Debian
and like its user (mail) interface.

Apart from that, you might want to consider building the issue tracker
on top of MH.


meillo
Julien Jehannet
2012-01-13 09:32:05 UTC
Permalink
Post by Anselm R Garbe
Post by a***@gmail.com
I might be interested in trying to help write one such suckless
issue tracker as requested on the webpage.
I just want to ask;
What set of features are a must for you?
Oh what a relief someone wants to volunteer on this idea.
One of the most important things of such a tracker is decent mail
integration in my opinion (as most trackers that have evolved in the
OSS space recently suck very much when it comes to mail integration).
What about roundup - http://roundup.sourceforge.net ?
I don't use it myself but it was already adopted by some major teams like
the mercurial crew for example.
However, It's also very handy to be able to download issue history in a
mbox format as bugzilla does (in case you're not subscribed) but I'm not
sure it's possible in roundup configuration.

Regards,
Kai Hendry
2012-01-15 05:08:44 UTC
Permalink
Post by Anselm R Garbe
One aspect of this tracker could be to start with a proper mail
archiving system and then writing the web stuff on top. This would
+1 on decent HTML5 Web interface on a maildir or something. I think
this is a precursor to any project that wants decent email
integration.

I tried to write this but failed. I was feeding my maildirs through
dovecot, like so:

printf "1 select inbox\n2 thread references us-ascii all\n3 fetch 1:*
envelope\n4 logout\n" |
/usr/local/libexec/dovecot/imap 2>/dev/null

And then using the data structure it produces to produce HTML. I ran
into some problem and I'll happily share the crappy shell code if
someone is interested.
Anselm R Garbe
2012-01-15 07:06:55 UTC
Permalink
Post by Anselm R Garbe
One of the most important things of such a tracker is decent mail
integration in my opinion (as most trackers that have evolved in the
OSS space recently suck very much when it comes to mail integration).
One aspect of this tracker could be to start with a proper mail
archiving system and then writing the web stuff on top. This would
allow proper querying. The mail archiving could be based on a
repository storage (hg or git) instead of some poor database based
system.
The reason I suggest to base the bug tracker "view" on a mail
archiving tool is simply because this problem hasn't been solved in an
acceptable way either (and we'd need a better system anyways).

I wouldn't go as far as asking for a web app, rather a proper static
mail archive generator that can be indexed by popular search engines
easily.

The logic aspect of the bug tracker should be controlled by mail
addresses only (I don't like the mail header approach, just make it
absolutely simple and work on mail addresses). One way I imagine this
could be:


New issue is reported to: ***@suckless.org (which is a read-only
mailing list otherwise). When the new issue is received the BTS will
prefix the subject to:

[id] <previous subject>

For example

[89] dwm crashes if I click on the status bar on any Friday the 13th

The BTS will also register the recipient:

bug-***@suckless.org -> status is "NEW"

(in the above example bug-***@suckless.org)

Afterwards all bug-related communication targets this email address. A
suckless developer with the permission to amend the bug status could
now send special commands to this address:


bug-id+***@suckless.org (accepts and opens the bug, indicating work
in progress) -> status changes to "IN PROGRESS"

bug-id+***@suckless.org (rejects the bug and closes it) -> status
changes to "CLOSED: INVALID"

bug-id+***@suckless.org (closes the bug and marks it as fixed) ->
status changes to "CLOSED: FIXED"


Once a bug has been closed with "+invalid" or "+fixed" the BTS will
subsequent mails to bug-***@suckless.org.

Comments or confirmations of a fix have to be send prior to "+invalid"
or "+fixed".

If someone is unhappy that a bug was closed, issue a new bug. Closing
a bug should be a final operation (in my experience this is one
problem with the existing BTS that allow re-opening closed bugs, but
re-opening closed bugs means your working style sucks)

That's how I imagine it.


Cheers,
Anselm
Suraj N. Kurapati
2012-01-15 07:49:23 UTC
Permalink
Post by Anselm R Garbe
If someone is unhappy that a bug was closed, issue a new bug. Closing
a bug should be a final operation (in my experience this is one
problem with the existing BTS that allow re-opening closed bugs, but
re-opening closed bugs means your working style sucks)
Perhaps the BTS could do this automatically on behalf of lazy users?

If I add a new comment to a closed bug, the BTS could create a new bug
for me, setting my comment as the bug description, while linking the two
bugs together.
--
Civilization, as we know it, will end sometime this evening.
See SYSNOTE tomorrow for more information.
hiro
2012-01-15 12:48:56 UTC
Permalink
Post by Anselm R Garbe
Afterwards all bug-related communication targets this email address. A
suckless developer with the permission to amend the bug status could
This is bullshit. An email address is no command line interface.
Stephen Paul Weber
2012-01-15 14:07:09 UTC
Permalink
Post by Anselm R Garbe
The reason I suggest to base the bug tracker "view" on a mail
archiving tool is simply because this problem hasn't been solved in an
acceptable way either (and we'd need a better system anyways).
Yes, this is a good problem to solve for many reasons.
Post by Anselm R Garbe
The logic aspect of the bug tracker should be controlled by mail
addresses only (I don't like the mail header approach, just make it
absolutely simple and work on mail addresses)
While I agree that adding custom headers is likely to be a pain and make
users come up with hacks, some headers are very well standardized. Most
notably In-Reply-To and Message-ID. IMHO, and "id" for the bug should be
the Message-ID of the original email, and any "comments" should be
In-Reply-To said email. That way you can just reply to a bug from your
email client and it works. Just like a mailing list :)
--
Stephen Paul Weber, @singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph
Paul Onyschuk
2012-01-15 15:45:48 UTC
Permalink
On Sun, 15 Jan 2012 14:07:09 +0000
Post by Stephen Paul Weber
While I agree that adding custom headers is likely to be a pain and
make users come up with hacks, some headers are very well
standardized. Most notably In-Reply-To and Message-ID. IMHO, and
"id" for the bug should be the Message-ID of the original email, and
any "comments" should be In-Reply-To said email. That way you can
just reply to a bug from your email client and it works. Just like a
mailing list :)
Valid email message must contain at least the following entries in
header [1] [2]:

- From
- Date
- Message-ID
- (only for reply msg) In-Reply-To

"Subject" is not required by specifications, but in practice
it is a standard. Anyway that means you'll get at least 4 lines
overhead for first message and 5 lines header for replies. Removing
that can lead to weird behavior.


[1] http://tools.ietf.org/html/rfc5322#section-3.6
[2] http://tools.ietf.org/html/rfc5322#section-3.6.4
Paul Onyschuk
2012-01-13 14:27:26 UTC
Permalink
On Thu, 12 Jan 2012 19:34:09 +0200
Post by a***@gmail.com
I might be interested in trying to help write one such suckless issue
tracker as requested on the webpage.
I just want to ask;
What set of features are a must for you?
After reading some discussion I have some ideas. For small projects
keeping TODO file in repository can work quite well. What about
extending this idea?

Use one of the mbox mail formats to store data:

- mbox file per issue
- treat first message in mbox as meta: modify and store common
informations (priority, short description, category of issue and so on)
there
- store everything under version control system: closed/resolved issues
can be moved to different branch (smaller checkout)

This way data can be accessed very easily, some usage ideas:

- searching for existing issues simple as checking out repository and
"greping" files
- nice time-line provided by version control system (history of
commits): when issue was updated, closed, new response was send
- advanced usage e.g. search for issues with specific priority, "cat"
them into one file and open with your email client

I think that would make some people happy. Use mailing list as main
interface, web interface could just send messages to list. Every
message would be automatically prefixed with issue ID, ID would be also
used as name for mbox file. Version control system would provide some
security against corruption (just rollback to previous working
checkout).

Anyway those are just random ideas, not sure if that is the way to go.


On Thu, 12 Jan 2012 18:58:16 +0000
Post by a***@gmail.com
What's wrong with GNATS?
OpenBSD bugtracker (GNATS) is down for some time and they aren't in
hurry to fix that. I think that says a lot about GNATS.
markus schnalke
2012-01-13 14:48:43 UTC
Permalink
Post by Paul Onyschuk
- treat first message in mbox as meta: modify and store common
informations (priority, short description, category of issue and so on)
there
No, put meta information in the header, where it belongs to. anno(1)
from MH does it for you.

Any newer message might change these attributes. Well, you might want
to update these attributes in the first message, to have the latest
state there, but in its header. Also, the change history would still
be available. I don't know how debbugs stores the meta data, but their
change history is great. Be sure to play with it.


meillo
Paul Onyschuk
2012-01-13 16:28:19 UTC
Permalink
On Fri, 13 Jan 2012 15:48:43 +0100
Post by markus schnalke
No, put meta information in the header, where it belongs to. anno(1)
from MH does it for you.
Any newer message might change these attributes. Well, you might want
to update these attributes in the first message, to have the latest
state there, but in its header. Also, the change history would still
be available. I don't know how debbugs stores the meta data, but their
change history is great. Be sure to play with it.
What makes old plain TODO interesting is zero setup offline usage and
direct access to data (checkout repository and open in your favorite
editor).

I don't see how Debbugs is improvement in this case - hide data behind
mailing list. Why I need to setup MH (or other mailing client) and
download mail archive or use fancy web interface just to look up (read
access) for existing issues?

I would say there is no difference between flat files database and SQL
database if you can't easily play with it (at least read access). Some
Post by markus schnalke
Unfortunately, the ”metadata” is just the raw HTML notes included in
the web pages, which isn’t amenable to translation or parsing.
Mbox formats are human readable, and file per issues makes it
accessible. Throwing everything into one file (like mbox mail archive)
or splitting everything into zillon files (file per message like
maildir) requires additional techniques/tools just to find interesting
issue.

History of issues in many cases is just garbage. What I need is status
of issue and responses to specific issue. Git/Mercurial or any other
version control system can provide history if you really need that.
Almost every open source projects nowadays gives read access to source
code repository, so what is the point of writing custom log format?
This way you can also track interesting issues without subscribing to
mailing list or using web interface.

Right now best interfaces for issue trackers are search engines (e.g.
Google "site:adress_of_bug_tracker interesting issue") and mail
archives (Gmane and so on) in my opinion.


[1] http://debconf5.debconf.org/comas/general/proposals/file/paper.ps
Kurt H Maier
2012-01-13 18:17:13 UTC
Permalink
Post by Paul Onyschuk
What makes old plain TODO interesting is zero setup offline usage and
direct access to data (checkout repository and open in your favorite
editor).
and then it turns into a huge mess when some vim nerd has expandtab
turned on.
Post by Paul Onyschuk
I don't see how Debbugs is improvement in this case - hide data behind
mailing list. Why I need to setup MH (or other mailing client) and
download mail archive or use fancy web interface just to look up (read
access) for existing issues?
this works both ways. why do I need another code checkout just to look
at existing issues? you clearly already have a mail client, you're
clearly already subscribed to lists.
Post by Paul Onyschuk
I would say there is no difference between flat files database and SQL
database if you can't easily play with it (at least read access). Some
I can't even begin to describe how much worse an RDBMS backing store is
as an idea. I don't care what format gets used as long as it isn't
binary (i.e. sqlite, mysql, db44, other such shit)
Post by Paul Onyschuk
Mbox formats are human readable, and file per issues makes it
accessible. Throwing everything into one file (like mbox mail archive)
or splitting everything into zillon files (file per message like
maildir) requires additional techniques/tools just to find interesting
issue.
when the spam comes in you're going to want a way to delete that. from
a tool-writing perspective that's probably easiest on maildir.
Post by Paul Onyschuk
This way you can also track interesting issues without subscribing to
mailing list or using web interface.
So what? With a mail interface you can track interesting issues without
having to install Python and check out a mercurial repository.
Post by Paul Onyschuk
Right now best interfaces for issue trackers are search engines (e.g.
Google "site:adress_of_bug_tracker interesting issue") and mail
archives (Gmane and so on) in my opinion.
Note that 'hg repos' wasn't on the list you just provided. Mail
archives were.

debbugs is a bit overblown. As a systems administrator I've had the
profound displeasure of interacting with dozens of issue trackers over
the years; everything from RT to Trac to JIRA and on and on. The
problem is always the same: people want bug trackers to do too much.
All you really need is a good mail gateway and a decent way to browse.
A mailing list, with the archive accessible in source control of some
kind, sounds absolutely fantastic. All you really need as far as
metadata is a string for project name, a small enum for status (i.e.,
new, in-progress, fixed, rejected), and an index number. The Agile
programming idiots will tell you different, but anything more than that
list is a completely useless distraction.

I used to be partial to werq[1] (no relation to Uriel's werc), but that was
long ago and I might be remembering it more fondly than it deserved.
Best Practical started work on something called sd[2] which was backed by
their weird distributed db called Prophet. The backing store and
replication mechanisms were a little ridiculous, but at least it shows
that even Best Practical considers the bug-tracking problem unsolved...
and they've been working on RT since the dawn of time.



1- http://www.math.duke.edu/~yu/wreq/
2- http://syncwith.us/sd/
Paul Onyschuk
2012-01-13 19:23:14 UTC
Permalink
On Fri, 13 Jan 2012 13:17:13 -0500
Post by Kurt H Maier
debbugs is a bit overblown. As a systems administrator I've had the
profound displeasure of interacting with dozens of issue trackers over
the years; everything from RT to Trac to JIRA and on and on. The
problem is always the same: people want bug trackers to do too much.
All you really need is a good mail gateway and a decent way to browse.
A mailing list, with the archive accessible in source control of some
kind, sounds absolutely fantastic. All you really need as far as
metadata is a string for project name, a small enum for status (i.e.,
new, in-progress, fixed, rejected), and an index number. The Agile
programming idiots will tell you different, but anything more than
that list is a completely useless distraction.
I'm not sure if you like or dislike my ideas, so I'll give further
explanations.

Debbugs uses separate email address for every issue. Store mail
archive for every of those addresses in mbox format. Sounds familiar?
Store that in version control system and use as backend of bugtracker
instead of writing custom flat text format and log format.

Write access (main interface) should be provided by sending email
messages like Debbugs, maybe simplified in some cases. Side effect of
using mbox files stored under version control system is that they can
be viewed (optional read access) also by text editor or your favorite
mail client.
a***@gmail.com
2012-01-14 07:25:14 UTC
Permalink
So:
* Binary is a no no.
* Issues are stored in one way or another as mail(s).
* That sits under a version control.

And an issue has the fields:
* status
* id
* project

I am guessing what project it belongs to will already be in the address fileld. and the id will be in the subject.
If foldered mail format is used; status of an issue can be determined by which folder it is at.

I am not very knowledgable when it comes to the use cases of a issue tracking tool. That's why I need to know what you guys want and do not want.
Keep it going guys.
hiro
2012-01-14 10:54:58 UTC
Permalink
mail sucks
markus schnalke
2012-01-14 11:01:09 UTC
Permalink
Post by hiro
mail sucks
... the start of a flame! *yay*


Please define what you mean with ``mail''.


meillo
hiro
2012-01-14 11:53:44 UTC
Permalink
I don't even remember sending this mail, sorry.
Post by markus schnalke
Post by hiro
mail sucks
... the start of a flame! *yay*
Please define what you mean with ``mail''.
meillo
Pieter Praet
2012-01-14 11:02:31 UTC
Permalink
Post by hiro
mail sucks
It may very well be because I'm awake since yesterday, but (taking
into account the message you replied to) that was goddamn hilarious!

Thanks!


Peace
--
Pieter
Anselm R Garbe
2012-01-15 06:38:17 UTC
Permalink
Post by Kurt H Maier
All you really need is a good mail gateway and a decent way to browse.
A mailing list, with the archive accessible in source control of some
kind, sounds absolutely fantastic.  All you really need as far as
metadata is a string for project name, a small enum for status (i.e.,
new, in-progress, fixed, rejected), and an index number. The Agile
Exactly.

-Anselm
markus schnalke
2012-01-13 21:48:04 UTC
Permalink
Post by Paul Onyschuk
On Fri, 13 Jan 2012 15:48:43 +0100
Mbox formats are human readable, and file per issues makes it
accessible. Throwing everything into one file (like mbox mail archive)
or splitting everything into zillon files (file per message like
maildir) requires additional techniques/tools just to find interesting
issue.
As you put all mails to one issue into one mbox file, you can put
mails into one mail folder as well. There's no difference there.
Post by Paul Onyschuk
History of issues in many cases is just garbage. What I need is status
of issue and responses to specific issue. Git/Mercurial or any other
version control system can provide history if you really need that.
Almost every open source projects nowadays gives read access to source
code repository, so what is the point of writing custom log format?
No custom log format, you just add some mail header lines to a new
message on receiving, that's all. At least to me, that appears to be
natural.
Post by Paul Onyschuk
This way you can also track interesting issues without subscribing to
mailing list or using web interface.
I haven't said anything about mailing lists or web interfaces. But
well, you surely want a web interface (at least read-only) and you
probably want be able to subscribe to issues. The mail interface
really is the important part, as Anselm already said. When you want
control it by email, then consider building it upon email.
Post by Paul Onyschuk
Right now best interfaces for issue trackers are search engines (e.g.
Google "site:adress_of_bug_tracker interesting issue") and mail
archives (Gmane and so on) in my opinion.
Unless you want to make changes ...


meillo
Paul Onyschuk
2012-01-13 22:35:33 UTC
Permalink
On Fri, 13 Jan 2012 22:48:04 +0100
Post by markus schnalke
Unless you want to make changes ...
"Abandon all hope, ye who enter here". My personal workaround is to
join IRC channel (or spam mailing list) and force developer/commiter to
create issue. Ugly hack, but works most of the times.
Hank Donnay
2012-01-13 23:22:12 UTC
Permalink
I like the idea of maildir-in-git, it makes something like automatically
generating a website trivial with hooks.
Post by Paul Onyschuk
On Fri, 13 Jan 2012 22:48:04 +0100
Post by markus schnalke
Unless you want to make changes ...
"Abandon all hope, ye who enter here". My personal workaround is to
join IRC channel (or spam mailing list) and force developer/commiter to
create issue. Ugly hack, but works most of the times.
--
--hank
hiro
2012-01-14 01:25:03 UTC
Permalink
Most issue tracker entries are full of stupid garbage we don't want
anyway. What worked great was the script we once had on the wmii irc
channel which just appended sentences beginning with BUG to the
buggfile.
Editing the sentences and then deleting all useless entries or
redundant letters keeps everything tidy. And from your text editor you
can just save the edited content to TODO.
Paul Onyschuk
2012-01-14 11:26:45 UTC
Permalink
On Fri, 13 Jan 2012 17:22:12 -0600
Post by Hank Donnay
I like the idea of maildir-in-git, it makes something like
automatically generating a website trivial with hooks.
Maildir is a bit overkill in my opinion, just look at naming convention
[1]. If you want to use "file per message" format, MH provides simpler
solution (name of file is just a ID number e.g. 1, 2, 15 and so on).


On Sat, 14 Jan 2012 02:25:03 +0100
Post by Hank Donnay
Editing the sentences and then deleting all useless entries or
redundant letters keeps everything tidy. And from your text editor you
can just save the edited content to TODO.
It could work nicely with MH mail format. Just delete redundant
message stored as file and push to repository. Edit content/header of
first message and you're done.

Creating shell/awk (or whatever you use) script for creating issue by
directly writing to repository shouldn't be much problem either.
Although folder naming of issues should be based on hashes created with
some salt in this case to avoid conflicts. Editing/modifying is smaller
problem I think - version control systems can handle pretty well
merging.

On Fri, 13 Jan 2012 15:48:43
Post by Hank Donnay
Well, you might want to update these attributes in the first
message, to have the latest state there, but in its header.
I don't see a point of storing meta-information in header of every
message. In my opinion headers of every message beside first one
should be stripped to minimum ("From", "To" and "Subject" etc).
Otherwise you'll get 20 or so lines for header just to accompany few
words long body e.g. "Check [xxxxxx] revision and let me know if that
fixed bug for you".

With mailing list-like interface those could be send, but storing that
is whole different case.

On Sat, 14 Jan 2012 09:25:14 +0200
Post by Hank Donnay
I am not very knowledgable when it comes to the use cases of a issue
tracking tool. That's why I need to know what you guys want and do
not want. Keep it going guys.
The problem is that it is easier to answer question "How issue tracker
should not look like" than other way around. Maybe there is a better
way to write suckless issue tracker than current proposals.


[1] http://cr.yp.to/proto/maildir.html
hiro
2012-01-14 11:52:17 UTC
Permalink
Maybe you shouldn't write software because you're bored.
Martti Kühne
2012-01-14 14:12:06 UTC
Permalink
Post by hiro
Maybe you shouldn't write software because you're bored.
Can't think of a more educating alternative, really. ;)
Ahmet Emre Çepoğlu
2012-01-14 16:16:51 UTC
Permalink
Post by hiro
Maybe you shouldn't write software because you're bored.
Why are you telling me this? I did not say once that I was doing this
because I was bored. Only because people know more than me, I should
sit in the corner and watch? If that is actually the case, please let
me know so I do not bother at all.
Connor Lane Smith
2012-01-14 16:27:38 UTC
Permalink
Post by Ahmet Emre Çepoğlu
Why are you telling me this? I did not say once that I was doing this
because I was bored.
He's just a (pretty lame) troll.

cls
hiro
2012-01-14 20:35:44 UTC
Permalink
I did not say once that I was doing this...
Perhaps you overlooked the word "maybe", so I'll still try to answer
-- disregard my rage -- with a question:

Why might you be interested in trying to help write one such suckless
issue tracker as requested on the webpage?
Alex Hutton
2012-01-15 02:27:28 UTC
Permalink
It seems to me it might overly complicate things to build the issue
tracker into a mail system or into git.

The core functionality of tracking issues can be implemented in a meta-language.

For instance, you have one file per issue, and the issue files would
look something like this.

[timestamp] : Issue #XXX [Issue name] Opened by [user1 name]
[timestamp] : Issue #XXX Status set to ABC by [user1 name]
[timestamp] : Issue #XXX Description at (/path/to/description) by [user1 name]
[timestamp] : Issue #XXX added tags (tag1,tag2,tag3) by [user1 name]
[timestamp] : Issue #XXX assigned to [user2 name] by [user1 name]
[timestamp] : Issue #XXX related email at (/path/to/email) sent by [user2 name]
[timestamp] : Issue #XXX related email at (/path/to/email) received by
[***@external.com]

etc etc.

You then have different daemons reading and writing to the file and
carrying out various functions. For instance, you have some mailer
that reads that an issue was assigned to a particular person, so it
knows it should send an email to that person. A CI server could create
issues when it detects a regression. Any daemon reading the file
should ignore lines it doesn't understand, that way as new features
are added to the meta-language the daemons won't break if they don't
understand them.

Issue files could be stored in a directory structure organised by
time. There could be special directories containing symlinks to the
issue files, for instance an 'Active issues' directory.


Cheers,
Alex
Paul Onyschuk
2012-01-15 13:22:50 UTC
Permalink
On Sun, 15 Jan 2012 13:27:28 +1100
Post by Alex Hutton
It seems to me it might overly complicate things to build the issue
tracker into a mail system or into git.
The core functionality of tracking issues can be implemented in a meta-language.
Static web generators (werc/ikiwiki etc) doesn't store that either.
Focus on most recent content and let version control system handle the
rest. I don't see why issue tracker can't do the same.

For every issue use mother message with recent informations (status
Post by Alex Hutton
git commit -m 'Issue #XXX [Issue name] Opened by [user1 name]'
hg commit -m 'Issue #XXX Status set to ABC by [user1 name]'
I know that storing different mail archive in repository and sending
something else to mail archive (e.g. bugs@) is questionable. Think
about this as cleaned up mail archive. Spam, trash talk, redundant
reports will always get to the mailing list (bugs@). Of course you can
remove that from inbox, but every user will go through the same
process. On other hand you can keep clean mail archive in repository
pretty easily.

Someone already suffered the pain of cleaning up the mess, so you can:
(A) Fetch mail archive of issue tracker with only relevant informations.
(B) Generate static web content and use Google/DDG to search through
non-crippled data.
Kurt H Maier
2012-01-15 14:27:17 UTC
Permalink
Post by Alex Hutton
It seems to me it might overly complicate things to build the issue
tracker into a mail system or into git.
The core functionality of tracking issues can be implemented in a meta-language.
are you even listening to yourself?
Alex Hutton
2012-01-16 03:00:09 UTC
Permalink
Post by Kurt H Maier
Post by Alex Hutton
It seems to me it might overly complicate things to build the issue
tracker into a mail system or into git.
The core functionality of tracking issues can be implemented in a meta-language.
are you even listening to yourself?
What if the bug tracker can be updated via web, cli and/or irc? Does
it make sense for each of those to fire off an email every time a bug
is changed?
Kurt H Maier
2012-01-15 14:25:33 UTC
Permalink
Post by Paul Onyschuk
Maildir is a bit overkill in my opinion, just look at naming convention
[1]. If you want to use "file per message" format, MH provides simpler
solution (name of file is just a ID number e.g. 1, 2, 15 and so on).
really? that's your big objection? the fucking *filename*? you want
to use an alternative, less-widely-supported alternative because of
the *filenames*?
Post by Paul Onyschuk
It could work nicely with MH mail format. Just delete redundant
message stored as file and push to repository. Edit content/header of
first message and you're done.
anything you have to say in support of mh also applies to maildir,
except for maybe stuff about the color of the shed
Post by Paul Onyschuk
Otherwise you'll get 20 or so lines for header just to accompany few
words long body e.g. "Check [xxxxxx] revision and let me know if that
fixed bug for you".
Your MUA should be able to hide headers you don't care about (even if
your MUA is "grep -v")
Post by Paul Onyschuk
The problem is that it is easier to answer question "How issue tracker
should not look like" than other way around. Maybe there is a better
way to write suckless issue tracker than current proposals.
Anselm and I have apparently independently arrived at similar goals for
a project like this. Everyone has a different idea of a 'good' bug
tracker, and you can basically gauge their experience based on how much
stupid shit they want to cram into it. If they want more data than id,
status, and maybe project, they're just naive.
Hank Donnay
2012-01-20 18:14:15 UTC
Permalink
After playing with a test maildir, I'm less convinced of the ease of use
of that setup. It takes some config abuse of my mail client of choice
(mutt) to get it to not send messages and instead just store in the
local dir.
Post by Kurt H Maier
Post by Paul Onyschuk
Maildir is a bit overkill in my opinion, just look at naming convention
[1]. If you want to use "file per message" format, MH provides simpler
solution (name of file is just a ID number e.g. 1, 2, 15 and so on).
really? that's your big objection? the fucking *filename*? you want
to use an alternative, less-widely-supported alternative because of
the *filenames*?
Post by Paul Onyschuk
It could work nicely with MH mail format. Just delete redundant
message stored as file and push to repository. Edit content/header of
first message and you're done.
anything you have to say in support of mh also applies to maildir,
except for maybe stuff about the color of the shed
Post by Paul Onyschuk
Otherwise you'll get 20 or so lines for header just to accompany few
words long body e.g. "Check [xxxxxx] revision and let me know if that
fixed bug for you".
Your MUA should be able to hide headers you don't care about (even if
your MUA is "grep -v")
Post by Paul Onyschuk
The problem is that it is easier to answer question "How issue tracker
should not look like" than other way around. Maybe there is a better
way to write suckless issue tracker than current proposals.
Anselm and I have apparently independently arrived at similar goals for
a project like this. Everyone has a different idea of a 'good' bug
tracker, and you can basically gauge their experience based on how much
stupid shit they want to cram into it. If they want more data than id,
status, and maybe project, they're just naive.
--
--hank
Kai Hendry
2012-01-15 05:02:40 UTC
Permalink
Post by Paul Onyschuk
Right now best interfaces for issue trackers are search engines (e.g.
Google "site:adress_of_bug_tracker interesting issue") and mail
archives (Gmane and so on) in my opinion.
I don't think they are the "best interfaces". It's the only option as
projects like Debian can't get a search engine together to search the
amount of data they generate.

https://groups.google.com/forum/#!forum/linux.debian.bugs.dist

A good Web interface would have options to manipulate the bug inline etc etc
Christoph Lohmann
2012-01-15 12:11:03 UTC
Permalink
Greetings.
Post by Kai Hendry
Post by Paul Onyschuk
Right now best interfaces for issue trackers are search engines (e.g.
Google "site:adress_of_bug_tracker interesting issue") and mail
archives (Gmane and so on) in my opinion.
I don't think they are the "best interfaces". It's the only option as
projects like Debian can't get a search engine together to search the
amount of data they generate.
https://groups.google.com/forum/#!forum/linux.debian.bugs.dist
A good Web interface would have options to manipulate the bug inline etc etc
There is no such thing as a »good Web interface«.


Sincerely,

Christoph Lohmann
Paul Hoffman
2012-01-26 00:40:45 UTC
Permalink
Post by Paul Onyschuk
On Thu, 12 Jan 2012 19:34:09 +0200
Post by a***@gmail.com
I might be interested in trying to help write one such suckless issue
tracker as requested on the webpage.
I just want to ask;
What set of features are a must for you?
After reading some discussion I have some ideas. For small projects
keeping TODO file in repository can work quite well. What about
extending this idea?
- mbox file per issue
- treat first message in mbox as meta: modify and store common
informations (priority, short description, category of issue and so on)
there
Ick.
Post by Paul Onyschuk
- store everything under version control system: closed/resolved issues
can be moved to different branch (smaller checkout)
Interesting.
Post by Paul Onyschuk
- searching for existing issues simple as checking out repository and
"greping" files
Yay.
Post by Paul Onyschuk
- nice time-line provided by version control system (history of
commits): when issue was updated, closed, new response was send
Double yay.
Post by Paul Onyschuk
- advanced usage e.g. search for issues with specific priority, "cat"
them into one file and open with your email client
Excellent.
Post by Paul Onyschuk
I think that would make some people happy.
Sounds like some good ideas to me.
Post by Paul Onyschuk
Use mailing list as main interface, web interface could just send
messages to list. Every message would be automatically prefixed with
issue ID, ID would be also used as name for mbox file. Version control
system would provide some security against corruption (just rollback
to previous working checkout).
I'm not crazy about shoehorning issue tracking into e-mail like this,
it's more complicated than it needs to be. Concentrate on simple, basic
storage and functions and let someone else who cares about a web
interface write one.
Post by Paul Onyschuk
Anyway those are just random ideas, not sure if that is the way to go.
That's good for starters. Here's a simple issue tracker repository
using directories, key-value text files, and symlinks:

/path/to/repo/
ticket/
abc123/
+owner/
yolanda -> ../../../user/yolanda
properties [status, description, whatever]
history [log of activity, append-only]
mail/ [maildir, mh mailbox, whatever]
+attachments/
hjk987 -> ../../../attachment/hjk987
user/
yolanda/
+tickets/
abc123 -> ../../../ticket/abc123
properties [name, e-mail address, etc.]
attachment/
hjk987/
properties
contents.foo [the file itself]

Simple, extensible (group/*, project/*, ticket/*/+watchers,
ticket/*/+parent, whatever), and if for some reason you don't want
symlinks you can manage the relationships between things some other way
(hard links, plain text files, whatever).

Call it nfuit (non-fucked up issue tracker) and write some shell
functions for convenience:

nfuit_create_repository nfuit_create_repository /path/to/another/repo
nfuit_create nfuit_create user/bob -name Bob -email ***@example.net
nfuit_set nfuit_set user/$u -name $name -email $addr
nfuit_properties nfuit_properties user/bob | while read key val; do ...; done
nfuit_log nfuit_log $(nfuit_now) ticket/123 created -by bob -status open
nfuit_exists if !nfuit_exists ticket/999; then ...; fi
nfuit_link nfuit_link user/bob +tickets ticket/666
nfuit_unlink # obvious
nfuit_links for t in $(nfuit_links user/yolanda +tickets); do ...; done
nfuit_is_linked if nfuit_is_linked user/$u +tickets ticket/123; then ...; fi
nfuit_lock nfuit_lock user/bob/properties
nfuit_unlock nfuit_unlock user/bob/properties

I've done most of this (in zsh). Then build the rest on top of this and
utils like grep, find, munpack, etc.

Paul.
--
Paul Hoffman <***@nkuitse.com>
Aurélien Aptel
2012-02-03 18:26:23 UTC
Permalink
So, how are things going? I guess setting up an existing BTS on
suckless.org while waiting is out of the question?
I'm already using some sort of TODO/XXX in comment but it could be better...

For what it's worth, here's my usecase/design/whatever. I don't need much:
- basic interface (cli, mail, http, ...) really don't care as long as
it's usable and not too complex
- title, description, status, comments
- *every* field above should be editable
Ahmet Emre Çepoğlu
2012-02-08 09:53:10 UTC
Permalink
Post by Paul Hoffman
Post by Paul Onyschuk
- store everything under version control system: closed/resolved issues
can be moved to different branch (smaller checkout)
Interesting.
Post by Paul Onyschuk
- searching for existing issues simple as checking out repository and
"greping" files
Yay.
Post by Paul Onyschuk
- nice time-line provided by version control system (history of
commits): when issue was updated, closed, new response was send
Double yay.
Post by Paul Onyschuk
- advanced usage e.g. search for issues with specific priority, "cat"
them into one file and open with your email client
Excellent.
Post by Paul Onyschuk
I think that would make some people happy.
Sounds like some good ideas to me.
Post by Paul Onyschuk
Use mailing list as main interface, web interface could just send
messages to list. Every message would be automatically prefixed with
issue ID, ID would be also used as name for mbox file. Version control
system would provide some security against corruption (just rollback
to previous working checkout).
I'm not crazy about shoehorning issue tracking into e-mail like this,
it's more complicated than it needs to be. Concentrate on simple, basic
storage and functions and let someone else who cares about a web
interface write one.
Post by Paul Onyschuk
Anyway those are just random ideas, not sure if that is the way to go.
That's good for starters. Here's a simple issue tracker repository
/path/to/repo/
ticket/
abc123/
+owner/
yolanda -> ../../../user/yolanda
properties [status, description, whatever]
history [log of activity, append-only]
mail/ [maildir, mh mailbox, whatever]
+attachments/
hjk987 -> ../../../attachment/hjk987
user/
yolanda/
+tickets/
abc123 -> ../../../ticket/abc123
properties [name, e-mail address, etc.]
attachment/
hjk987/
properties
contents.foo [the file itself]
Simple, extensible (group/*, project/*, ticket/*/+watchers,
ticket/*/+parent, whatever), and if for some reason you don't want
symlinks you can manage the relationships between things some other way
(hard links, plain text files, whatever).
Call it nfuit (non-fucked up issue tracker) and write some shell
nfuit_create_repository nfuit_create_repository /path/to/another/repo
nfuit_set nfuit_set user/$u -name $name -email $addr
nfuit_properties nfuit_properties user/bob | while read key val; do ...; done
nfuit_log nfuit_log $(nfuit_now) ticket/123 created -by bob -status open
nfuit_exists if !nfuit_exists ticket/999; then ...; fi
nfuit_link nfuit_link user/bob +tickets ticket/666
nfuit_unlink # obvious
nfuit_links for t in $(nfuit_links user/yolanda +tickets); do ...; done
nfuit_is_linked if nfuit_is_linked user/$u +tickets ticket/123; then ...; fi
nfuit_lock nfuit_lock user/bob/properties
nfuit_unlock nfuit_unlock user/bob/properties
I've done most of this (in zsh). Then build the rest on top of this and
utils like grep, find, munpack, etc.
Paul.
--
Paul Hoffman
Well, this sounds functional enough, but... I feel that maybe I am
considering it to be simpler than it actually is. This is what I understand:
-Now, the issue tracker application manages the creation and modification
of a folder as you said.
-All the issue tracking data sits in this folder. This folder sits inside a
version-controlled folder (so, this folder replaces the TODO files we swap
around, if you place it together with the source code)
-Then all I have to do is write a simple bash or C program with a couple of
features (like the ones you listed).
- If control through email is requested, another app should be written that
extends an email handling system.
- If anyone wants a web interface, that too would be done with another
application.

Something this simple I feel would have been done already. What am I
missing?
If nothing, I could get started right away.

Cheers
Anselm R Garbe
2012-02-08 19:15:52 UTC
Permalink
Post by Ahmet Emre Çepoğlu
That's good for starters.  Here's a simple issue tracker repository
/path/to/repo/
   ticket/
       abc123/
           +owner/
               yolanda -> ../../../user/yolanda
           properties [status, description, whatever]
           history [log of activity, append-only]
           mail/ [maildir, mh mailbox, whatever]
           +attachments/
               hjk987 -> ../../../attachment/hjk987
   user/
       yolanda/
           +tickets/
               abc123 -> ../../../ticket/abc123
           properties [name, e-mail address, etc.]
   attachment/
       hjk987/
           properties
           contents.foo [the file itself]
Simple, extensible (group/*, project/*, ticket/*/+watchers,
ticket/*/+parent, whatever), and if for some reason you don't want
symlinks you can manage the relationships between things some other way
(hard links, plain text files, whatever).
Call it nfuit (non-fucked up issue tracker) and write some shell
nfuit_create_repository  nfuit_create_repository /path/to/another/repo
nfuit_create             nfuit_create user/bob -name Bob -email
nfuit_set                nfuit_set user/$u -name $name -email $addr
nfuit_properties         nfuit_properties user/bob | while read key val;
do ...; done
nfuit_log                nfuit_log $(nfuit_now) ticket/123 created -by bob
-status open
nfuit_exists             if !nfuit_exists ticket/999; then ...; fi
nfuit_link               nfuit_link user/bob +tickets ticket/666
nfuit_unlink             # obvious
nfuit_links              for t in $(nfuit_links user/yolanda +tickets); do
...; done
nfuit_is_linked          if nfuit_is_linked user/$u +tickets ticket/123;
then ...; fi
nfuit_lock               nfuit_lock user/bob/properties
nfuit_unlock             nfuit_unlock user/bob/properties
I've done most of this (in zsh).  Then build the rest on top of this and
utils like grep, find, munpack, etc.
Well, this sounds functional enough, but... I feel that maybe I am
-Now, the issue tracker application manages the creation and modification of
a folder as you said.
-All the issue tracking data sits in this folder. This folder sits inside a
version-controlled folder (so, this folder replaces the TODO files we swap
around, if you place it together with the source code)
-Then all I have to do is write a simple bash or C program with a couple of
features (like the ones you listed).
- If control through email is requested, another app should be written that
extends an email handling system.
- If anyone wants a web interface, that too would be done with another
application.
Something this simple I feel would have been done already. What am I
missing?
If nothing, I could get started right away.
I find this idea quite interesting and would love to see this as a
prototype. Just sticking to a world-writable repo like our wiki for
the issue tracking, sounds fine.

I'm not sure about Pauls directory structure suggestion though, but it
looks ok for a start.

The web interface could be a simple rc extension for werc.

Btw. I would like you to use C and rc, not C and bash or something similar.

Cheers,
Anselm
Hadrian Węgrzynowski
2012-02-09 09:16:01 UTC
Permalink
On Wed, 8 Feb 2012 20:15:52 +0100
Post by Anselm R Garbe
Btw. I would like you to use C and rc, not C and bash or something similar.
There were once discussion about "blessed" rc version, but AFAIR there
were no simple conclusion. What version of rc is good enough?
What I remember: Byron's version is cursed and p9p version is too big.
So which one is good?

I don't intend to make another thread out of this, but I would really
appreciate simple answer.

IMHO sh is acceptable also, but only for simplistic version.
Anselm R Garbe
2012-02-09 19:35:05 UTC
Permalink
Post by Hadrian Węgrzynowski
On Wed, 8 Feb 2012 20:15:52 +0100
Post by Anselm R Garbe
Btw. I would like you to use C and rc, not C and bash or something similar.
There were once discussion about "blessed" rc version, but AFAIR there
were no simple conclusion. What version of rc is good enough?
What I remember: Byron's version is cursed and p9p version is too big.
So which one is good?
Of course

http://tools.suckless.org/9base
Post by Hadrian Węgrzynowski
IMHO sh is acceptable also, but only for simplistic version.
If it is plain sh, it is ok, but 9base would be preferred.

There will be a new 9base-7 release soon as well.

Cheers,
Anselm
Christian Neukirchen
2012-02-10 00:58:49 UTC
Permalink
Post by Paul Onyschuk
Post by Hadrian Węgrzynowski
On Wed, 8 Feb 2012 20:15:52 +0100
Post by Anselm R Garbe
Btw. I would like you to use C and rc, not C and bash or something similar.
There were once discussion about "blessed" rc version, but AFAIR there
were no simple conclusion. What version of rc is good enough?
What I remember: Byron's version is cursed and p9p version is too big.
So which one is good?
Of course
http://tools.suckless.org/9base
This one is even more bloated than the others:

text data bss dec hex filename
77360 632 7496 85488 14df0 /home/chris/src/rc-1.7.1/rc-static-musl
81682 2088 6344 90114 16002 /home/chris/src/rc-1.7.1/rc-dyn-glibc
116849 3520 18272 138641 21d91 /opt/plan9/bin/rc-dyn-glibc
154252 4480 20120 178852 2baa4 /home/chris/src/9base/rc/rc-static-musl
862556 8176 28824 899556 db9e4 /home/chris/src/9base/rc/rc-static-glibc

(Yes, the statically linked musl version is smaller than the dynamically
linked glibc version of the same program.)
--
Christian Neukirchen <***@gmail.com> http://chneukirchen.org
Jacob Todd
2012-02-10 03:03:02 UTC
Permalink
By bloated you mean the binary size is a miniscule; practically
meaningless, amount larger than the others. That hardly counts as bloated.
Post by Christian Neukirchen
Post by Paul Onyschuk
Post by Hadrian Węgrzynowski
On Wed, 8 Feb 2012 20:15:52 +0100
Post by Anselm R Garbe
Btw. I would like you to use C and rc, not C and bash or something similar.
There were once discussion about "blessed" rc version, but AFAIR there
were no simple conclusion. What version of rc is good enough?
What I remember: Byron's version is cursed and p9p version is too big.
So which one is good?
Of course
http://tools.suckless.org/9base
text data bss dec hex filename
77360 632 7496 85488 14df0
/home/chris/src/rc-1.7.1/rc-static-musl
81682 2088 6344 90114 16002
/home/chris/src/rc-1.7.1/rc-dyn-glibc
116849 3520 18272 138641 21d91 /opt/plan9/bin/rc-dyn-glibc
154252 4480 20120 178852 2baa4
/home/chris/src/9base/rc/rc-static-musl
862556 8176 28824 899556 db9e4
/home/chris/src/9base/rc/rc-static-glibc
(Yes, the statically linked musl version is smaller than the dynamically
linked glibc version of the same program.)
--
Anselm R Garbe
2012-02-10 07:00:27 UTC
Permalink
Post by Christian Neukirchen
Post by Paul Onyschuk
Post by Hadrian Węgrzynowski
On Wed, 8 Feb 2012 20:15:52 +0100
Post by Anselm R Garbe
Btw. I would like you to use C and rc, not C and bash or something similar.
There were once discussion about "blessed" rc version, but AFAIR there
were no simple conclusion. What version of rc is good enough?
What I remember: Byron's version is cursed and p9p version is too big.
So which one is good?
Of course
http://tools.suckless.org/9base
text data bss dec hex filename
77360 632 7496 85488 14df0
/home/chris/src/rc-1.7.1/rc-static-musl
Post by Christian Neukirchen
81682 2088 6344 90114 16002
/home/chris/src/rc-1.7.1/rc-dyn-glibc
Post by Christian Neukirchen
116849 3520 18272 138641 21d91 /opt/plan9/bin/rc-dyn-glibc
154252 4480 20120 178852 2baa4
/home/chris/src/9base/rc/rc-static-musl
Post by Christian Neukirchen
862556 8176 28824 899556 db9e4 /hom
e/chris/src/9base/rc/rc-static-glibc
Post by Christian Neukirchen
(Yes, the statically linked musl version is smaller than the dynamically
linked glibc version of the same program.)
You are comparing Byrons rc rape with the original rc of 9base here? If so
then this is kind of apples and oranges. Byrons rc was written for lunix
environments and Posix, whereas the original rc was in use on Plan 9.

So not a surprise that Byrons version is a bit smaller as a static binary
on yet another lunix box.

Cheers
Anselm
Kai Hendry
2012-01-15 05:15:10 UTC
Permalink
Post by a***@gmail.com
What set of features are a must for you?
It pains me to say this, but the best BTS I've come across is
https://www.pivotaltracker.com/

Seriously.

It has great Web interface and a decent mail integration. You really
should study this.


I think Github's issue interface https://github.com/dashboard/issues
is pretty OK.


I'm gone down the TODO list http://webconverger.org/todo/ and it's not
"social" enough I dare say. You need commenting and +1 and all that
crap nowadays, to keep interested.
Kurt H Maier
2012-01-15 14:28:56 UTC
Permalink
Post by Kai Hendry
I'm gone down the TODO list http://webconverger.org/todo/ and it's not
"social" enough I dare say. You need commenting and +1 and all that
crap nowadays, to keep interested.
if you need stupid games to keep people interested then those people
have no business contributing to anything
Anselm R Garbe
2012-02-11 10:06:49 UTC
Permalink
| > €I'm coming in late to an ongoing discussion: it sounds like there's
| > something wrong with Byron's version of rc apart from being written from
| > scratch for Unix (and not quite implementing Plan 9 rc syntax, since it
| > doesn't have 'if not'). Do you have a pointer to where I could read more
| > about this?
|
| I'm not aware of a an in-depth analysis of all differences, but the
|
| - Byron introduced the export keyword
| - Byron broke the default syntax with the else keyword (vs if not)
| - Byron does not export functions into the environment
| - Byron does not export variables into the environment
| - No rcmain counterpart in Byrons version
|
| I'm sure I have missed some other aspects.
 Hmm, something is odd here. I am a long-term user of the Byron version
of rc (I started using it when it was the only choice for an rc-like
thing on Unix), and the main version I have used and always seen does
not have an export keyword and automatically exports functions and
variables into the environment[*]. It does have the two defects of else
vs 'if not' and not having an rcmain.
(I just grabbed the rc-1.7.1 source from http://rc-shell.slackmatic.org/
and verified this in the manpage.)
 If there is some mutant version of Byron's rc with these three things,
it is, well, surprisingly mutant. I'd go so far as to call it mutilated.
Ok, I might have consumed my Byron rc hacks that resulted in an
obscure rci version (about 10 years ago) with Byrons version. I
apologize for remembering this wrong and take back the two
accusations.
[Another difference between Byron rc and Plan 9 rc is that Byron rc
can run a function every time before the prompt is printed; I don't
think this is part of Plan 9 rc, or at least I can't find it in the
manpage.]
Ok, good point.

Thanks,
Anselm
Aurélien Aptel
2012-07-23 18:59:12 UTC
Permalink
Let's bump this again. Someone might do something about it.
Kai Hendry
2012-07-24 16:48:25 UTC
Permalink
The github issue tracker is pretty nice for issue tracking.

On the subject of mbox viewer, hopefully Scott's work can be carried
on https://github.com/bytbox/go-mail

Loading...