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] [dwm] Tags vs Monitors
On Thu, Jan 12, 2012 at 18:09:15 +, Rob wrote: I would imagine that the (or my at least) workflow could be much smoother if there was only one tagset, independently of the number of monitors, and if there were (a) layout(s) suitable for multi-screen views. The first useful layout for two monitors that would come to my mind would consist of two master windows plus one stack on one of the two monitors. What do you guys think? How do you make efficient use of two monitors? Do you find the current tag/monitor paradigm useful? I would be very interested in your opinions. I had this thought, but how would you implement it? What if you selected the same tagset on each monitor? You can only display a window in a single place, so it couldn't be on both monitors at the same time, think about it. It can't be done unless you can somehow clone the window or something (I'm not very clued up on X11). This problem would come up if there was only one tagset and each monitor would be an independent view whose visible tags could be set independently. I rather meant that there should be only one tagset, and all monitors together would form a combined view, i.e. both monitors would always have the same set of tags visible. Each window should still be assigned a definite monitor. I'm sorry if my previous description was unclear, and hope that this one clarifies it.
Re: [dev] [dwm] Tags vs Monitors
On Thu, Jan 12, 2012 at 17:44:56 -0500, TJ Robotham wrote: But with two monitors, I constantly find myself moving windows between the two, and searching for windows that I lost because I put them on the other monitor, which makes them lose their previously assigned tags. You might find it helpful to go into sendmon and delete that one line that resets the window's tags to whatever's currently visible on the other monitor. That was pretty much the first thing I did when multihead support was added, since I rarely want to both move a window between monitors and retag it. Thank's a lot for this hint! This would result in almost exactly what I want. In fact, if combined with a patch that would keep the set of visible tags on both screens in sync, I think it would be exactly what I want. Does anyone know how to achieve the latter?
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] [dwm] Tags vs Monitors
On Fri, Jan 13, 2012 at 11:32:42AM +0100, Thomas Dean wrote: This problem would come up if there was only one tagset and each monitor would be an independent view whose visible tags could be set independently. I rather meant that there should be only one tagset, and all monitors together would form a combined view, i.e. both monitors would always have the same set of tags visible. Each window should still be assigned a definite monitor. I'm sorry if my previous description was unclear, and hope that this one clarifies it. Oh, yeah I got the wrong end of the stick, I thought you meant a tagset which was shared between each monitor or something, thanks for clearing that up. Personally I prefer the way it's set up at the moment, but I'd be interested in seeing any patches anyway. Cheers, Rob
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] [dwm] Tags vs Monitors
Þann fös 13.jan 2012 10:32, skrifaði Thomas Dean: This problem would come up if there was only one tagset and each monitor would be an independent view whose visible tags could be set independently. I rather meant that there should be only one tagset, and all monitors together would form a combined view, i.e. both monitors would always have the same set of tags visible. Each window should still be assigned a definite monitor. I'm sorry if my previous description was unclear, and hope that this one clarifies it. That sounds great. At that point I would in fact expect dynamic monitor assignment.
Re: [dev] [dwm] Tags vs Monitors
On Fri, Jan 13, 2012 at 11:35:02AM +0100, Thomas Dean wrote: On Thu, Jan 12, 2012 at 17:44:56 -0500, TJ Robotham wrote: You might find it helpful to go into sendmon and delete that one line that resets the window's tags to whatever's currently visible on the other monitor. That was pretty much the first thing I did when multihead support was added, since I rarely want to both move a window between monitors and retag it. Thank's a lot for this hint! This would result in almost exactly what I want. In fact, if combined with a patch that would keep the set of visible tags on both screens in sync, I think it would be exactly what I want. Does anyone know how to achieve the latter? Check /(toggle)?(view|tag)/ functions in dwm.c Or you could change arrange() so it sets the tagset for all other monitors too Rob
Re: [dev] [dwm] Tags vs Monitors
On Fri, Jan 13, 2012 at 21:48:47 +, Bjartur Thorlacius wrote: This problem would come up if there was only one tagset and each monitor would be an independent view whose visible tags could be set independently. I rather meant that there should be only one tagset, and all monitors together would form a combined view, i.e. both monitors would always have the same set of tags visible. Each window should still be assigned a definite monitor. I'm sorry if my previous description was unclear, and hope that this one clarifies it. That sounds great. At that point I would in fact expect dynamic monitor assignment. I think that's what I meant in my first email by layout(s) suitable for multiple screens.
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.
