Re: [dev] interested in issue tracker dev
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
Re: [dev] interested in issue tracker dev
Let's bump this again. Someone might do something about it.
Re: [dev] interested in issue tracker dev
On 10 February 2012 18:25, Chris Siebenmann c...@cs.toronto.edu wrote: | €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 | main ones are: | | - 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
Re: [dev] interested in issue tracker dev
On Wed, 8 Feb 2012 20:15:52 +0100 Anselm R Garbe garb...@gmail.com wrote: 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.
Re: [dev] interested in issue tracker dev
On 9 February 2012 10:16, Hadrian Węgrzynowski hadr...@hawski.com wrote: On Wed, 8 Feb 2012 20:15:52 +0100 Anselm R Garbe garb...@gmail.com wrote: 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 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
Re: [dev] interested in issue tracker dev
On Thu, Jan 26, 2012 at 2:40 AM, Paul Hoffman nkui...@nkuitse.com wrote: - store everything under version control system: closed/resolved issues can be moved to different branch (smaller checkout) Interesting. This way data can be accessed very easily, some usage ideas: - searching for existing issues simple as checking out repository and greping files Yay. - nice time-line provided by version control system (history of commits): when issue was updated, closed, new response was send Double yay. - advanced usage e.g. search for issues with specific priority, cat them into one file and open with your email client Excellent. I think that would make some people happy. Sounds like some good ideas to me. 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. 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 b...@example.net nfuit_setnfuit_set user/$u -name $name -email $addr nfuit_properties nfuit_properties user/bob | while read key val; do ...; done nfuit_lognfuit_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
Re: [dev] interested in issue tracker dev
On 8 February 2012 10:53, Ahmet Emre Çepoğlu aecepo...@gmail.com wrote: On Thu, Jan 26, 2012 at 2:40 AM, Paul Hoffman nkui...@nkuitse.com wrote: 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 b...@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. 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. 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
Re: [dev] interested in issue tracker dev
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
Re: [dev] interested in issue tracker dev
On Fri, Jan 13, 2012 at 03:27:26PM +0100, Paul Onyschuk wrote: On Thu, 12 Jan 2012 19:34:09 +0200 aecepoglu@ wrote: 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 Ick. - store everything under version control system: closed/resolved issues can be moved to different branch (smaller checkout) Interesting. This way data can be accessed very easily, some usage ideas: - searching for existing issues simple as checking out repository and greping files Yay. - nice time-line provided by version control system (history of commits): when issue was updated, closed, new response was send Double yay. - advanced usage e.g. search for issues with specific priority, cat them into one file and open with your email client Excellent. I think that would make some people happy. Sounds like some good ideas to me. 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. 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 b...@example.net nfuit_setnfuit_set user/$u -name $name -email $addr nfuit_properties nfuit_properties user/bob | while read key val; do ...; done nfuit_lognfuit_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 nkui...@nkuitse.com
Re: [dev] interested in issue tracker dev
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. On Sun, Jan 15, 2012 at 09:25:33AM -0500, Kurt H Maier wrote: On Sat, Jan 14, 2012 at 12:26:45PM +0100, Paul Onyschuk wrote: 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*? 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 Otherwise you'll get 20 or so lines for header just to accompany few words long body e.g. Check [xx] 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) 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 pgpLefN6wpo7h.pgp Description: PGP signature
Re: [dev] interested in issue tracker dev
Greetings. Kai Hendry wrote: On 14 January 2012 00:28, Paul Onyschuk bl...@bojary.koba.pl wrote: 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
Re: [dev] interested in issue tracker dev
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: This is bullshit. An email address is no command line interface.
Re: [dev] interested in issue tracker dev
On Sun, 15 Jan 2012 13:27:28 +1100 Alex Hutton wrote: 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 and everything else needed) and then just modify it: 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.
Re: [dev] interested in issue tracker dev
Somebody claiming to be Anselm R Garbe wrote: On 12 January 2012 19:06, Anselm R Garbe garb...@gmail.com wrote: 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. 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
Re: [dev] interested in issue tracker dev
On Sat, Jan 14, 2012 at 12:26:45PM +0100, Paul Onyschuk wrote: 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*? 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 Otherwise you'll get 20 or so lines for header just to accompany few words long body e.g. Check [xx] 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) 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.
Re: [dev] interested in issue tracker dev
On Sun, Jan 15, 2012 at 01:27:28PM +1100, Alex Hutton wrote: 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?
Re: [dev] interested in issue tracker dev
On Sun, Jan 15, 2012 at 01:15:10PM +0800, Kai Hendry wrote: 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
Re: [dev] interested in issue tracker dev
On Sun, 15 Jan 2012 14:07:09 + Stephen Paul Weber wrote: 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
Re: [dev] interested in issue tracker dev
On 16 January 2012 01:27, Kurt H Maier khm-suckl...@intma.in wrote: On Sun, Jan 15, 2012 at 01:27:28PM +1100, Alex Hutton wrote: 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?
Re: [dev] interested in issue tracker dev
mail sucks
Re: [dev] interested in issue tracker dev
On Sat, 14 Jan 2012 11:54:58 +0100, hiro 23h...@googlemail.com wrote: 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
Re: [dev] interested in issue tracker dev
On Fri, 13 Jan 2012 17:22:12 -0600 Hank Donnay wrote: 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 hiro wrote: 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 +0100 markus schnalke wrote: 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 [xx] 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 aecepoglu@ wrote: 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
Re: [dev] interested in issue tracker dev
Maybe you shouldn't write software because you're bored.
Re: [dev] interested in issue tracker dev
On 1/14/12, hiro 23h...@googlemail.com wrote: 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.
Re: [dev] interested in issue tracker dev
On 14 January 2012 16:16, Ahmet Emre Çepoğlu aecepo...@gmail.com wrote: 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
Re: [dev] interested in issue tracker dev
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?
Re: [dev] interested in issue tracker dev
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 [exter...@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
Re: [dev] interested in issue tracker dev
On 14 January 2012 00:28, Paul Onyschuk bl...@bojary.koba.pl wrote: 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
Re: [dev] interested in issue tracker dev
On 13 January 2012 02:06, Anselm R Garbe garb...@gmail.com wrote: 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.
Re: [dev] interested in issue tracker dev
On 13 January 2012 19:17, Kurt H Maier khm-suckl...@intma.in wrote: 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
Re: [dev] interested in issue tracker dev
On 12 January 2012 19:06, Anselm R Garbe garb...@gmail.com wrote: 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: b...@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+w...@suckless.org (accepts and opens the bug, indicating work in progress) - status changes to IN PROGRESS bug-id+inva...@suckless.org (rejects the bug and closes it) - status changes to CLOSED: INVALID bug-id+fi...@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
Re: [dev] interested in issue tracker dev
On Sun 15 Jan 2012 08:06:55 AM PST, Anselm R Garbe wrote: 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.
Re: [dev] interested in issue tracker dev
2012/1/12 markus schnalke mei...@marmaro.de [2012-01-12 19:06] Anselm R Garbe garb...@gmail.com On 12 January 2012 18:34, aecepo...@gmail.com wrote: 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,
Re: [dev] interested in issue tracker dev
On Thu, 12 Jan 2012 19:34:09 +0200 aecepoglu@ wrote: 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 + Bjartur Thorlacius wrote: 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.
Re: [dev] interested in issue tracker dev
[2012-01-13 15:27] Paul Onyschuk bl...@bojary.koba.pl - 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
Re: [dev] interested in issue tracker dev
On Fri, 13 Jan 2012 15:48:43 +0100 markus schnalke wrote: 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 random note from Debbugs presentation paper [1]: 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
Re: [dev] interested in issue tracker dev
On Fri, Jan 13, 2012 at 05:28:19PM +0100, Paul Onyschuk wrote: 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. 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. 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 random note from Debbugs presentation paper [1]: 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) 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. 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. 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/
Re: [dev] interested in issue tracker dev
On Fri, 13 Jan 2012 13:17:13 -0500 Kurt H Maier wrote: 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.
Re: [dev] interested in issue tracker dev
[2012-01-13 17:28] Paul Onyschuk bl...@bojary.koba.pl On Fri, 13 Jan 2012 15:48:43 +0100 markus schnalke wrote: 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. 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. 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. 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
Re: [dev] interested in issue tracker dev
On Fri, 13 Jan 2012 22:48:04 +0100 markus schnalke wrote: 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.
Re: [dev] interested in issue tracker dev
I like the idea of maildir-in-git, it makes something like automatically generating a website trivial with hooks. On Fri, Jan 13, 2012 at 11:35:33PM +0100, Paul Onyschuk wrote: On Fri, 13 Jan 2012 22:48:04 +0100 markus schnalke wrote: 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 pgp55ACZyKgJO.pgp Description: PGP signature
Re: [dev] interested in issue tracker dev
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.
Re: [dev] interested in issue tracker dev
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.
[dev] interested in issue tracker dev
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.
Re: [dev] interested in issue tracker dev
On 12 January 2012 18:34, aecepo...@gmail.com wrote: 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
Re: [dev] interested in issue tracker dev
What's wrong with GNATS?
Re: [dev] interested in issue tracker dev
On 12 January 2012 19:58, Bjartur Thorlacius svartma...@gmail.com wrote: What's wrong with GNATS? Nearly everything. GNU, 50kSLOC, etc. Cheers, Anselm
Re: [dev] interested in issue tracker dev
[2012-01-12 19:06] Anselm R Garbe garb...@gmail.com On 12 January 2012 18:34, aecepo...@gmail.com wrote: 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
