From nicolas.pouillard at gmail.com Mon Sep 1 07:53:37 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Mon, 01 Sep 2008 13:53:37 +0200 Subject: [ditz-talk] What about labels? In-Reply-To: <1211723397-sup-238@ausone.local> References: <1209744474-sup-3166@ausone.local> <1211686071-sup-8952@south> <1211723397-sup-238@ausone.local> Message-ID: <1220269476-sup-5553@guest-rocq-135070.inria.fr> Excerpts from Nicolas Pouillard's message of Sun May 25 16:13:10 +0200 2008: > Excerpts from William Morgan's message of Sun May 25 05:39:49 +0200 2008: > > Reformatted excerpts from nicolas.pouillard's message of 2008-05-02: > > > I would like to have a little more expressivity/flexibility when > > > organizing issues with ditz. The 'component' feature is too > > > limited and I would like extend to something better. > > > > Well, no one has replied to this yet, which probably means no one > > objects. :) > > Sort of... > > > Personally I'd be fine with labels, since it's a lossless extension of > > the component idea. I don't see it as something that would immediately > > help me (since I mostly get what I want with ditz grep), but if there > > are a lot of issues, then it will become useful. (Wow, this is just like > > the Gmail / Sup story....) > > That's not a lossless extension, the thing you lost when switching to labels > is that an issue is no longer labeled by one and only one label. From the > user point of view is not a problem at all, from the code this means that > iterating over labels and searching for issues that have this labels leads to > iterating more than some issues and must treat specially unlabelled ones. > > However that's no big deal, as you will see in the published branch 'labels' > [1] that depends on 'after-deserialize-on-issues' and 'factorize-html'. > > > > (1) Would the feature kindly accepted? (assuming a consensus...) > > > (2) Should it replaces components? > > > (3) What becomes the short-name of issues? > > > (4) How to update the "display issues by component" to labels? > > > > > > Concerning (2), I think it should replace them. > > > > I agree. > > That's what I've done: > - in a backward compatible manner: > that is issue component are seen as having one label > - in a mostly forward compatible manner: > while using only one label per issue the issue is stored back > as usual. This work is now somewhat outdated by recent ditz changes. Before reworking it I would like to be sure that people/you want it. I plan to do it soon and I would like to be sure that's a good period to be reviewed. More precisely one have to choose between making this change backward compatible or not (if so one will provide a migration tool). The first version was backward compatible, but I've heard that issue types could be removed (tasks,bugs,features) and I think it could be a good reason to switch to labels. The migration tool will convert issues types and components into labels, making two labels per issue after the conversion, then people can choose to continue that way or remove labels to hide components and/or issue types. Cheers, -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From mitch at cgarbs.de Mon Sep 1 13:53:20 2008 From: mitch at cgarbs.de (Christian Garbs) Date: Mon, 1 Sep 2008 19:53:20 +0200 Subject: [ditz-talk] What about labels? In-Reply-To: <1220269476-sup-5553@guest-rocq-135070.inria.fr> References: <1209744474-sup-3166@ausone.local> <1211686071-sup-8952@south> <1211723397-sup-238@ausone.local> <1220269476-sup-5553@guest-rocq-135070.inria.fr> Message-ID: <20080901175320.GB11586@cgarbs.de> On Mon, Sep 01, 2008 at 01:53:37PM +0200, Nicolas Pouillard wrote: > [labels] > This work is now somewhat outdated by recent ditz changes. > > Before reworking it I would like to be sure that people/you want it. I don't really get what labels are. How do they compare to tags for example? Will they be like tags but removing the "primary key" of the bugs? Regards, Christian -- ....Christian.Garbs.....................................http://www.cgarbs.de Mirrors should reflect a little before throwing back images. -- Jean Cocteau -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From wmorgan-ditz at masanjin.net Mon Sep 1 14:34:07 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Mon, 01 Sep 2008 11:34:07 -0700 Subject: [ditz-talk] What about labels? In-Reply-To: <1220269476-sup-5553@guest-rocq-135070.inria.fr> References: <1209744474-sup-3166@ausone.local> <1211686071-sup-8952@south> <1211723397-sup-238@ausone.local> <1220269476-sup-5553@guest-rocq-135070.inria.fr> Message-ID: <1220293541-sup-6463@entry> Reformatted excerpts from nicolas.pouillard's message of 2008-09-01: > This work is now somewhat outdated by recent ditz changes. > > Before reworking it I would like to be sure that people/you want it. > > I plan to do it soon and I would like to be sure that's a good period > to be reviewed. I'd like to have it as a plugin. That way there will be no migration necessary---the component stuff is already optional (and might get dropped in the future because I think I'm the only one who uses it), so you could use the labels plugin either in conjunction with, or as a replacement for, components. The plugin system is designed exactly for things like this: just add a "labels" field to Ditz::Issue and add a bunch of commands to modify it. > The first version was backward compatible, but I've heard that issue > types could be removed (tasks,bugs,features) and I think it could be a > good reason to switch to labels. I'm still not sure whether I want to drop them, but labels would make it easier to do so. -- William From nicolas.pouillard at gmail.com Mon Sep 1 14:41:49 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Mon, 01 Sep 2008 20:41:49 +0200 Subject: [ditz-talk] What about labels? In-Reply-To: <20080901175320.GB11586@cgarbs.de> References: <1209744474-sup-3166@ausone.local> <1211686071-sup-8952@south> <1211723397-sup-238@ausone.local> <1220269476-sup-5553@guest-rocq-135070.inria.fr> <20080901175320.GB11586@cgarbs.de> Message-ID: <1220294435-sup-2512@ausone.local> Excerpts from Christian Garbs's message of Mon Sep 01 19:53:20 +0200 2008: > On Mon, Sep 01, 2008 at 01:53:37PM +0200, Nicolas Pouillard wrote: > > > [labels] > > > This work is now somewhat outdated by recent ditz changes. > > > > Before reworking it I would like to be sure that people/you want it. > > I don't really get what labels are. > How do they compare to tags for example? They are the same thing, this term was chosen by gmail, and reused by sup, so I keep this one. > Will they be like tags but removing the "primary key" of the bugs? In some way that's it. -- Nicolas Pouillard -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From nicolas.pouillard at gmail.com Mon Sep 1 14:57:35 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Mon, 01 Sep 2008 20:57:35 +0200 Subject: [ditz-talk] What about labels? In-Reply-To: <1220293541-sup-6463@entry> References: <1209744474-sup-3166@ausone.local> <1211686071-sup-8952@south> <1211723397-sup-238@ausone.local> <1220269476-sup-5553@guest-rocq-135070.inria.fr> <1220293541-sup-6463@entry> Message-ID: <1220294884-sup-1467@ausone.local> Excerpts from William Morgan's message of Mon Sep 01 20:34:07 +0200 2008: > Reformatted excerpts from nicolas.pouillard's message of 2008-09-01: > > This work is now somewhat outdated by recent ditz changes. > > > > Before reworking it I would like to be sure that people/you want it. > > > > I plan to do it soon and I would like to be sure that's a good period > > to be reviewed. > > I'd like to have it as a plugin. That way there will be no migration > necessary---the component stuff is already optional (and might get > dropped in the future because I think I'm the only one who uses it), so > you could use the labels plugin either in conjunction with, or as a > replacement for, components. I also use components, and a lot for one project. > The plugin system is designed exactly for things like this: just add a > "labels" field to Ditz::Issue and add a bunch of commands to modify it. OK, so you consider that components and/or issues types should go to plugins too? However I'm not sure that the plugin system is flexible enough add them completely (by grep-ing component in the code for instance...) > > The first version was backward compatible, but I've heard that issue > > types could be removed (tasks,bugs,features) and I think it could be a > > good reason to switch to labels. > > I'm still not sure whether I want to drop them, but labels would make it > easier to do so. I understand that the backward compatibility makes things harder. However IMHO some categorization have to be in core and that labels are simple and flexible. However I will try to do that tomorrow as a plugin. Best regards, -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From wmorgan-ditz at masanjin.net Mon Sep 1 21:47:11 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Mon, 01 Sep 2008 18:47:11 -0700 Subject: [ditz-talk] What about labels? In-Reply-To: <1220294884-sup-1467@ausone.local> References: <1209744474-sup-3166@ausone.local> <1211686071-sup-8952@south> <1211723397-sup-238@ausone.local> <1220269476-sup-5553@guest-rocq-135070.inria.fr> <1220293541-sup-6463@entry> <1220294884-sup-1467@ausone.local> Message-ID: <1220319784-sup-2457@entry> Reformatted excerpts from nicolas.pouillard's message of 2008-09-01: > OK, so you consider that components and/or issues types should go to > plugins too? However I'm not sure that the plugin system is flexible > enough add them completely (by grep-ing component in the code for > instance...) I'm thinking about it. I'm pretty sure the plugin system would be flexible enough to move components over... but this is all very low priority. I probably won't do anything for a while. > However I will try to do that tomorrow as a plugin. I'm happy to answer any questions that come up. Definitely check out the current plugins for examples. -- William From wmorgan-ditz at masanjin.net Mon Sep 1 22:09:57 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Mon, 01 Sep 2008 19:09:57 -0700 Subject: [ditz-talk] First impressions In-Reply-To: <8e50e92e0808251144j49f33604la705d526b38cff95@mail.gmail.com> References: <200807290315.16589.ninja@slaphack.com> <200808192229.06622.ninja@slaphack.com> <1219205251-sup-7036@entry> <200808200022.31134.ninja@slaphack.com> <1219624293-sup-3478@entry> <20080825172326.GA3662@cgarbs.de> <8e50e92e0808251144j49f33604la705d526b38cff95@mail.gmail.com> Message-ID: <1220320070-sup-3300@entry> It sounds like "#" is problematic for a couple reasons: 1. shells interpret it as a comment delimiter 2. false positives (we're #1!) 3. Debian bugs, and whatever else is out there. So I'm thinking about @ as the identifier, and allowing both decorated and non-decorated ids on the commandline. Specifically: on the commandline, accept 23, @23, , @, and component-23 as issue identifiers. In titles, comments and descriptions, accept only @23, @, and component-23. Add an option to the configuration which controls whether to display the numbers or the names in system output. (Probably defaulting to names for legacy support.) Obviously things like email addresses are going to have @'s in them, so Ditz will only interpolate when there's a match with an issue id, and otherwise will leave the text as is. There is one additional problem with the unadorned numbers on the commandline: they can conflict with hash id prefixes. Ditz currently raises an error if the prefixes collide, so this behavior will just be extended. So it's possible that using an unadorned number on the commandline will cause Ditz to abort with an error message. But that's life in the fast lane---if you want to be 100% sure you won't collide (say, in a shell script), use one of the other naming conventions. -- William From nicolas.pouillard at gmail.com Tue Sep 2 04:34:11 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Tue, 02 Sep 2008 10:34:11 +0200 Subject: [ditz-talk] First impressions In-Reply-To: <1220320070-sup-3300@entry> References: <200807290315.16589.ninja@slaphack.com> <200808192229.06622.ninja@slaphack.com> <1219205251-sup-7036@entry> <200808200022.31134.ninja@slaphack.com> <1219624293-sup-3478@entry> <20080825172326.GA3662@cgarbs.de> <8e50e92e0808251144j49f33604la705d526b38cff95@mail.gmail.com> <1220320070-sup-3300@entry> Message-ID: <1220344436-sup-1684@guest-rocq-135070.inria.fr> Excerpts from William Morgan's message of Tue Sep 02 04:09:57 +0200 2008: > It sounds like "#" is problematic for a couple reasons: > 1. shells interpret it as a comment delimiter > 2. false positives (we're #1!) > 3. Debian bugs, and whatever else is out there. > > So I'm thinking about @ as the identifier, and allowing both decorated > and non-decorated ids on the commandline. Sounds good to me. > Specifically: on the commandline, accept 23, @23, , @ prefix>, and component-23 as issue identifiers. In titles, comments and > descriptions, accept only @23, @, and component-23. Add > an option to the configuration which controls whether to display the > numbers or the names in system output. (Probably defaulting to names for > legacy support.) > > Obviously things like email addresses are going to have @'s in them, so > Ditz will only interpolate when there's a match with an issue id, and > otherwise will leave the text as is. > > There is one additional problem with the unadorned numbers on the > commandline: they can conflict with hash id prefixes. Ditz currently > raises an error if the prefixes collide, so this behavior will just be > extended. So it's possible that using an unadorned number on the > commandline will cause Ditz to abort with an error message. But that's > life in the fast lane---if you want to be 100% sure you won't collide > (say, in a shell script), use one of the other naming conventions. -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: not available URL: From nicolas.pouillard at gmail.com Tue Sep 2 04:46:48 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Tue, 02 Sep 2008 10:46:48 +0200 Subject: [ditz-talk] What about labels? In-Reply-To: <1220319784-sup-2457@entry> References: <1209744474-sup-3166@ausone.local> <1211686071-sup-8952@south> <1211723397-sup-238@ausone.local> <1220269476-sup-5553@guest-rocq-135070.inria.fr> <1220293541-sup-6463@entry> <1220294884-sup-1467@ausone.local> <1220319784-sup-2457@entry> Message-ID: <1220344497-sup-2516@guest-rocq-135070.inria.fr> Excerpts from William Morgan's message of Tue Sep 02 03:47:11 +0200 2008: > Reformatted excerpts from nicolas.pouillard's message of 2008-09-01: > > OK, so you consider that components and/or issues types should go to > > plugins too? However I'm not sure that the plugin system is flexible > > enough add them completely (by grep-ing component in the code for > > instance...) > > I'm thinking about it. I'm pretty sure the plugin system would be > flexible enough to move components over... but this is all very low > priority. I probably won't do anything for a while. I'm wondering if by making components a plugin, I could face up all problems with the labels plugin. Moreover components/'issue types' will becomes redundant (and awkward) for those with the labels plugin. > > However I will try to do that tomorrow as a plugin. > > I'm happy to answer any questions that come up. Definitely check out the > current plugins for examples. BTW what is the more recent branch edge or master? -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From matt at tplus1.com Tue Sep 2 08:53:27 2008 From: matt at tplus1.com (Matthew Wilson) Date: Tue, 2 Sep 2008 08:53:27 -0400 Subject: [ditz-talk] undefined method 'name' NoMethodError Message-ID: Hi, I just tried to start a ditz repository (I don't know if that's the right word) and got this traceback: $ ditz /usr/local/lib/site_ruby/1.8/ditz/model-objects.rb:124:in `validate!': undefined method `name' for "features":String (NoMethodError) from /usr/lib/ruby/1.8/yaml.rb:143:in `map' from /usr/local/lib/site_ruby/1.8/ditz/model-objects.rb:124:in `each' from /usr/local/lib/site_ruby/1.8/ditz/model-objects.rb:124:in `map' from /usr/local/lib/site_ruby/1.8/ditz/model-objects.rb:124:in `validate!' from /usr/local/lib/site_ruby/1.8/ditz/model-objects.rb:133:in `from' from /usr/local/lib/site_ruby/1.8/ditz/file-storage.rb:17:in `load' from /usr/bin/ditz:130 These are the commands I ran before hand: $ ditz # Asked me for my name $ ditz init # asked for the project name, asked for components, and I put in "features" $ ditz # this is what caused the error I'm running ditz 0.5, at least according to ditz --version. What am I doing wrong? Matt -- Matthew Wilson matt at tplus1.com http://tplus1.com 216-470-6058 From wmorgan-ditz at masanjin.net Tue Sep 2 11:23:49 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Tue, 02 Sep 2008 08:23:49 -0700 Subject: [ditz-talk] undefined method 'name' NoMethodError In-Reply-To: References: Message-ID: <1220368782-sup-8058@entry> Reformatted excerpts from Matthew Wilson's message of 2008-09-02: > /usr/local/lib/site_ruby/1.8/ditz/model-objects.rb:124:in `validate!': > undefined method `name' for "features":String (NoMethodError) It looks like the project file was generated incorrectly, I can't reproduce this. Can you paste your bugs/project.yaml, and a transcript of your ditz init session? Here's what I see: w at entry:/tmp$ ditz --version ditz 0.5 w at entry:/tmp$ ditz init I wasn't able to find a configuration file ./.ditz-config. We'll set it up right now. Your name (enter for "William Morgan"): Your email address (enter for "w at entry.masanjin.net"): Directory to store issues state in (enter for "bugs"): Project name (enter for "tmp"): Issues can be tracked across the project as a whole, or the project can be split into components, and issues tracked separately for each component. Track issues separately for different components? (y/n): y Current components: None! (A)dd component, (r)emove component, or (d)one: a Component name: features Current components: 1) features (A)dd component, (r)emove component, or (d)one: d Ok, bugs directory created successfully. w at entry:/tmp$ ditz Unassigned: No open issues. -- William From dcalford at distributel.ca Tue Sep 2 11:55:38 2008 From: dcalford at distributel.ca (Dalton Calford) Date: Tue, 02 Sep 2008 11:55:38 -0400 Subject: [ditz-talk] Dummies guide to ditz Message-ID: <1220370938.10464.78.camel@dcalford-laptop.corp.distributel.ca> Warning, long post. I am setting up a central git/ditz/gitpserver repository. I want to make sure that my assumptions are correct with the project, so I want to be as clear as to what I am doing and why, so that any mistakes I am making are caught. First, I am producing a git repository, on a linux (ubuntu) box. It is a shared repository with many projects, a git-pserver implementation and a web front end. I want ditz to be the issue tracker. I use ACL's to manage the low level file permissions as one or more groups may have r/w access, while one or more other groups would have r/o access, everyone else would not see the project. We use the windows domain controller to manage users and their group membership. The root of the repository is in the /home/git directory. Because git needs special settings to run as as cvs-pserver, we have put all the setup elements into a single script. The script would be run as a local user from the command prompt or it can be called from a web script (I can provide all of this to anyone who wants to know how it is done). I am going to give a text explanation as the script itself may be confusing to those who are not totally familiar with the environment. The script takes three arguments 1. project name 2. group name 3. user name (this is for the web script) After verifying user and group rights/existence on the server, the script performs the following steps 1. creates a directory in the /home/git/ directory with the same name as the project. -the directory is created as the user passed as $user 2. changes into the newly created directory and performs a "git --bare init --shared 3. creates a directory called ".notbare" and changes directory into it. 4. performs a "git-init --shared=all" and touches README (creating an empty README file) 5. performs a "git-add README" and a "git-commit -m 'Added README' README" 6. returns to the project directory. 7. fetches in the newly created .notbare project 8. gets rid of the .notbare project This is due to the needs of the git-pserver code to have existing material in the repository, and it needs to be in the proper location. for example, for a project called "foo" cd /home/git mkdir foo cd foo git -bare init --shared mkdir .notbare cd .notbare git-init --shared=all touch README git-add README git-commit -m 'Added README' cd /home/git/foo git-fetch .notbare rm -fr .notbare All the steps with the .notbare directory can be accomplished with a default empty project, but, as there is no guarentee that the end user would have such an animal, we go through all the steps. Now with the project needs a few more steps performed git-branch -M $project (create a branch with the project name) git-config gitcvs.enabled 1 git-config gitcvs.ext.enabled 1 touch cvs.log chmod 666 cvs.log git-config gitcvs.logfile `pwd`/cvs.log git-config gitcvs.ext.logfile `pwd`/cvs.log mkdir logs So now that the various setup stuff has been explained, now we get to the part about the git. 1. in the project directory, we create two files - .ditz-config and .ditz-plugins. The ditz-config file has standard settings (bugs directory etc) The plugins file has git, git-sync and issue-claiming enabled. 2. in the project directory we perform a ditz-init,a ditz-add-release and a ditz-release all via expect scripts. (I can provide the details on this for anyone who wants them) 3. we run 'ditz html' 4. we touch gitcvs.$project.sqlite we then setup all the file rights/permissions etc and make a link from our apache web tree to the html directory so that the web server always is pointing to the correct index.html for the project. So, here are my questions 1.) Since this is designed for remote work, only projects pushed or pulled into the repository work, so the ditz stuff is not really part of the repository - should they be added as part of the cvs setup code (ie where we create the readme file) and then fetched into the newly created repository? 2.) We want the issues to be able to be updated locally and merged into the project, how would you set up the repository to work with git? 3.) We are creating a web interface for ditz and I am currently reviewing the sheily code to see how that works - is anyone interested in this? best regards Dalton From matt at tplus1.com Tue Sep 2 13:30:30 2008 From: matt at tplus1.com (Matthew Wilson) Date: Tue, 2 Sep 2008 13:30:30 -0400 Subject: [ditz-talk] How to refer to bugs folder from subdirectories of project? Message-ID: I made my bugs folder in the top of my project. Do I always need to cd back to the top folder of my project when I want to read and write issues, or is there some way to refer to it throughout my checkout? Matt -- Matthew Wilson matt at tplus1.com http://tplus1.com 216-470-6058 From matt at tplus1.com Tue Sep 2 14:58:15 2008 From: matt at tplus1.com (Matthew Wilson) Date: Tue, 2 Sep 2008 14:58:15 -0400 Subject: [ditz-talk] Markdown or textile or HTML inside issue descriptions? Message-ID: Hi -- I'd like to use *something* to make my issues a little prettier. For example, I'd like to use
    tags, but it seems like HTML gets escaped. Is it possible to put this on the ditz roadmap? Maybe I could try to write a patch. Matt -- Matthew Wilson matt at tplus1.com http://tplus1.com 216-470-6058 From nicolas.pouillard at gmail.com Tue Sep 2 15:58:23 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Tue, 02 Sep 2008 21:58:23 +0200 Subject: [ditz-talk] What about labels? In-Reply-To: <1220344497-sup-2516@guest-rocq-135070.inria.fr> References: <1209744474-sup-3166@ausone.local> <1211686071-sup-8952@south> <1211723397-sup-238@ausone.local> <1220269476-sup-5553@guest-rocq-135070.inria.fr> <1220293541-sup-6463@entry> <1220294884-sup-1467@ausone.local> <1220319784-sup-2457@entry> <1220344497-sup-2516@guest-rocq-135070.inria.fr> Message-ID: <1220385412-sup-7300@ausone.local> Excerpts from Nicolas Pouillard's message of Tue Sep 02 10:46:48 +0200 2008: > Excerpts from William Morgan's message of Tue Sep 02 03:47:11 +0200 2008: > > Reformatted excerpts from nicolas.pouillard's message of 2008-09-01: > > > OK, so you consider that components and/or issues types should go to > > > plugins too? However I'm not sure that the plugin system is flexible > > > enough add them completely (by grep-ing component in the code for > > > instance...) > > > > I'm thinking about it. I'm pretty sure the plugin system would be > > flexible enough to move components over... but this is all very low > > priority. I probably won't do anything for a while. > > I'm wondering if by making components a plugin, I could face up all problems > with the labels plugin. > > Moreover components/'issue types' will becomes redundant (and awkward) for > those with the labels plugin. > > > > However I will try to do that tomorrow as a plugin. Well, I've sent two merge requests. The first one is about to fix some recent bugs in ditz found while testing labels, and an addition. The second add the plugin for labels. Best regards, -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From mitch at cgarbs.de Tue Sep 2 16:16:14 2008 From: mitch at cgarbs.de (Christian Garbs) Date: Tue, 2 Sep 2008 22:16:14 +0200 Subject: [ditz-talk] How to refer to bugs folder from subdirectories of project? In-Reply-To: References: Message-ID: <20080902201614.GA18623@cgarbs.de> On Tue, Sep 02, 2008 at 01:30:30PM -0400, Matthew Wilson wrote: > I made my bugs folder in the top of my project. > > Do I always need to cd back to the top folder of my project when I > want to read and write issues, Using the "ditz" command to read and write your issues also works from subdirectories. Eg. having /home/user/someproject/bugs, the ditz command will work in /home/user/someproject, /home/user/someproject/subdir and /home/user/someproject/some_dir/some_other_dir > or is there some way to refer to it throughout my checkout? If your version control commits all changed files in the repository (assuming that everything under /home/user/someproject is tracked), your changed will be included automatically. For new issues, a hint is displayed after adding the issue saying "you might have to add the following file to your source control". This includes a valid path, eg. something like ../../../bug/issue-xxxxxx So everything should just work. Regards, Christian -- ....Christian.Garbs.....................................http://www.cgarbs.de The idea is to die young as late as possible (Ashley Montagu) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From mitch at cgarbs.de Tue Sep 2 16:24:47 2008 From: mitch at cgarbs.de (Christian Garbs) Date: Tue, 2 Sep 2008 22:24:47 +0200 Subject: [ditz-talk] What about labels? In-Reply-To: <1220294435-sup-2512@ausone.local> References: <1209744474-sup-3166@ausone.local> <1211686071-sup-8952@south> <1211723397-sup-238@ausone.local> <1220269476-sup-5553@guest-rocq-135070.inria.fr> <20080901175320.GB11586@cgarbs.de> <1220294435-sup-2512@ausone.local> Message-ID: <20080902202447.GC18623@cgarbs.de> On Mon, Sep 01, 2008 at 08:41:49PM +0200, Nicolas Pouillard wrote: > Excerpts from Christian Garbs's message of Mon Sep 01 19:53:20 +0200 2008: > > I don't really get what labels are. How do they compare to tags > > for example? > They are the same thing, this term was chosen by gmail, and reused > by sup, so I keep this one. Tags/Labels are useful, I think. They could supersede components or the task/bug/issue type. One could also think of using tags like 'wontfix', 'security' or 'wishlist' like with the Debian bugs. > > Will they be like tags but removing the "primary key" of the bugs? > In some way that's it. I don't think I'd like that :-) I like to have a unique identifier for an issue - even when it is a slowly-changing thing like the current ditz ids. While the real ID is the long unique issue id, it's impractical because it is too long to type. Something like "ditz-10" is easy to remember and use. If you remove the short issue id and introduce tags, how would that affect the workflow? Currently I look at the ditz todos, choose an id (say, ditz-10) and then do "ditz start ditz-10". If I only have labels instead of this id, what will ditz todo show? Will an issue be listed five times if it has five labels? With which id will it be listed if it has now label at all? Could you provide a fake "screenshot" of a label-enabled output of "ditz todo"? Regards, Christian -- ....Christian.Garbs.....................................http://www.cgarbs.de Das Schicksal besch?tzt Narren, kleine Kinder und Schiffe mit dem Namen Enterprise. (William T. Riker) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From wmorgan-ditz at masanjin.net Tue Sep 2 22:00:41 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Tue, 02 Sep 2008 19:00:41 -0700 Subject: [ditz-talk] Markdown or textile or HTML inside issue descriptions? In-Reply-To: References: Message-ID: <1220406681-sup-5585@entry> Reformatted excerpts from Matthew Wilson's message of 2008-09-02: > I'd like to use *something* to make my issues a little prettier. For > example, I'd like to use
      tags, but it seems like HTML gets > escaped. I think someone else brought this up recently too. I'd be fine with this. I've added issue 53310ae2. -- William From wmorgan-ditz at masanjin.net Tue Sep 2 22:14:02 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Tue, 02 Sep 2008 19:14:02 -0700 Subject: [ditz-talk] command line ditz In-Reply-To: <1220374762.21020.3.camel@dcalford-laptop.corp.distributel.ca> References: <1219412567.7581.2.camel@dcalford-laptop.corp.distributel.ca> <1219624940-sup-6459@entry> <1219668763.7205.1.camel@dcalford-laptop.corp.distributel.ca> <1219861183-sup-3519@entry> <1219933131.7045.5.camel@dcalford-laptop.corp.distributel.ca> <1219946903-sup-9253@entry> <1219965554-sup-9881@entry> <1220374762.21020.3.camel@dcalford-laptop.corp.distributel.ca> Message-ID: <1220407631-sup-4112@entry> Reformatted excerpts from Dalton Calford's message of 2008-09-02: > I have pulled down the latest version of ditz, git and sheila. > > What I don't understand is how they all work together. > > Is sheila a plugin? Is sheila called by ditz html to generate a > different html page? How is sheila called/invoked in order to test > it's output? Sheila is a Camping app, so you have to run it via the (latest git version) of Camping. If you run it from anywhere in your Ditz project, it will bring up its own server on port 3301. It uses webrick as the web server by default; you may want to install mongrel instead. Here's how to run it: 1. Make a new clone of the project you want to track bugs with. 2. Clone ditz from git://gitorious.org/ditz/mainline.git. 3. Clone camping from git://github.com/why/camping.git. 4. Clone sheila from git://github.com/wmorgan/sheila.git. 5. Within your project dir, run: ruby -I$CAMPING_ROOT/lib -I$DITZ_ROOT/lib -rubygems $CAMPING_ROOT/bin/camping $SHEILA_ROOT/sheila.rb where the environment variables have been set to the clone dirs above. (I realize this is all a little wonky, but that's life on the bleeding edge.) That will give you a webapp on port 3301 that you can use to add and view issues. Like I said, it's very preliminary and none of the git stuff is hooked up, so basically it will just tweak the Ditz files in your project dir and not synchronize them with anyone else. The next step is to make it commit the modifications. -- William From wmorgan-ditz at masanjin.net Tue Sep 2 22:17:21 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Tue, 02 Sep 2008 19:17:21 -0700 Subject: [ditz-talk] undefined method 'name' NoMethodError In-Reply-To: References: <1220368782-sup-8058@entry> Message-ID: <1220408065-sup-9172@entry> Reformatted excerpts from Matthew Wilson's message of 2008-09-02: > In your transcript, you got asked about tracking issues across a > project or by component. I just immediately got prompted for a > component. That is so weird. I literally cannot imagine what would cause that kind of behavior. > $ ditz init > I wasn't able to find a configuration file ./.ditz-config. > We'll set it up right now. > Your name (enter for "Matthew Wilson"): > Your email address (enter for "matt at sprout.tplus1.com"): matt at tplus1.com > Directory to store issues state in (enter for "bugs"): > Project name (enter for "ditzfun"): > Components: Wtf! Just for kicks, does the same thing happen with the latest git HEAD? You can just git clone git://gitorious.org/ditz/mainline.git and run "ruby bin/ditz" to try. -- William From wmorgan-ditz at masanjin.net Tue Sep 2 22:36:36 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Tue, 02 Sep 2008 19:36:36 -0700 Subject: [ditz-talk] Dummies guide to ditz In-Reply-To: <1220370938.10464.78.camel@dcalford-laptop.corp.distributel.ca> References: <1220370938.10464.78.camel@dcalford-laptop.corp.distributel.ca> Message-ID: <1220408514-sup-1831@entry> Reformatted excerpts from Dalton Calford's message of 2008-09-02: > 1.) Since this is designed for remote work, only projects pushed or > pulled into the repository work, so the ditz stuff is not really part of > the repository - should they be added as part of the cvs setup code (ie > where we create the readme file) and then fetched into the newly created > repository? I would recommend having the ditz files tracked by git alongside the code. I think that also answers this question: > 2.) We want the issues to be able to be updated locally and merged into > the project, how would you set up the repository to work with git? If the Ditz issue database (the bugs/ directory) is under version control, then this is taken care of for you by git. As long as no one is modifying the repo on the server directly (i.e. it's a 'bare' repo and is only pushed to and pulled from), then you're guaranteed no conflicts. If you're using 'ditz html', you probably want to have a git hook that runs that command when someone pushed a commit, If you're using sheila, you may have to do a little legwork to make it resync upon a git push. (Or maybe it should just periodically check the last modified time of the bugs directory and reload the project hwen that changes.) > 3.) We are creating a web interface for ditz and I am currently > reviewing the sheily code to see how that works - is anyone interested > in this? Yes, me. :) I didn't understand all the project creation stuff completely, but wouldn't it be easier to create a new project by just cloning a base project that had everything set up correctly, including the README, the ditz bugs/ directory and configuration, etc? Then you only have to create that thing once, and you don't need to write and maintain scripts that regenerate it. -- William From wmorgan-ditz at masanjin.net Tue Sep 2 23:13:15 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Tue, 02 Sep 2008 20:13:15 -0700 Subject: [ditz-talk] What about labels? In-Reply-To: <1220379491-sup-7477@ausone.local> References: <1209744474-sup-3166@ausone.local> <1211686071-sup-8952@south> <1211723397-sup-238@ausone.local> <1220269476-sup-5553@guest-rocq-135070.inria.fr> <1220293541-sup-6463@entry> <1220294884-sup-1467@ausone.local> <1220319784-sup-2457@entry> <1220344497-sup-2516@guest-rocq-135070.inria.fr> <1220370988-sup-7756@entry> <1220379491-sup-7477@ausone.local> Message-ID: <1220411519-sup-3778@entry> Reformatted excerpts from nicolas.pouillard's message of 2008-09-02: > What about removing the edge branch then? Or renaming it as old-edge > to avoid confusions? I could remove it. (I might want to bring it back at some point, just not when the project is this small.) Of course this would only affect the remote repo, and people would still have local edge branches in their repos. -- William From wmorgan-ditz at masanjin.net Tue Sep 2 23:23:55 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Tue, 02 Sep 2008 20:23:55 -0700 Subject: [ditz-talk] What about labels? In-Reply-To: <1220385412-sup-7300@ausone.local> References: <1209744474-sup-3166@ausone.local> <1211686071-sup-8952@south> <1211723397-sup-238@ausone.local> <1220269476-sup-5553@guest-rocq-135070.inria.fr> <1220293541-sup-6463@entry> <1220294884-sup-1467@ausone.local> <1220319784-sup-2457@entry> <1220344497-sup-2516@guest-rocq-135070.inria.fr> <1220385412-sup-7300@ausone.local> Message-ID: <1220411598-sup-8575@entry> Reformatted excerpts from nicolas.pouillard's message of 2008-09-02: > Well, I've sent two merge requests. The first one is about to fix some > recent bugs in ditz found while testing labels, and an addition. The > second add the plugin for labels. I've merged them in. Thanks, good stuff. (I actually just committed the same fix as your e008483d). A couple comments: 1. What was the point of: - @template_dir = File.dirname Ditz::find_ditz_file("share/ditz/index.rhtml") + @template_dir = File.dirname Ditz::find_ditz_file("../share/ditz/index.rhtml") Was something not working? Can I change it back? The behavior should be identical... 2. The problem with storing the label objects in project.yaml is that if two people both add a label, that file will conflict. So I think it would be better to recreate the Label objects on the fly when the project is loaded in. If you do that, you might not even need to serialize the Label object itself. Components, releases, etc are just stored as strings in issue objects, which makes the YAML easier to read and modify. (Components and releases are scheduled to move out of project.yaml too---see issue 80c02356). 3. I'd prefer add-label instead of new-label, in line with add-release, add-component, etc. Even better would be to just drop that step entirely, and have 'ditz label' autocreate the label. -- William From nicolas.pouillard at gmail.com Wed Sep 3 04:21:42 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Wed, 03 Sep 2008 10:21:42 +0200 Subject: [ditz-talk] What about labels? In-Reply-To: <1220411598-sup-8575@entry> References: <1209744474-sup-3166@ausone.local> <1211686071-sup-8952@south> <1211723397-sup-238@ausone.local> <1220269476-sup-5553@guest-rocq-135070.inria.fr> <1220293541-sup-6463@entry> <1220294884-sup-1467@ausone.local> <1220319784-sup-2457@entry> <1220344497-sup-2516@guest-rocq-135070.inria.fr> <1220385412-sup-7300@ausone.local> <1220411598-sup-8575@entry> Message-ID: <1220429713-sup-6202@ausone.inria.fr> Excerpts from William Morgan's message of Wed Sep 03 05:23:55 +0200 2008: > Reformatted excerpts from nicolas.pouillard's message of 2008-09-02: > > Well, I've sent two merge requests. The first one is about to fix some > > recent bugs in ditz found while testing labels, and an addition. The > > second add the plugin for labels. > > I've merged them in. Thanks, good stuff. (I actually just committed the > same fix as your e008483d). A couple comments: Great! > 1. What was the point of: > - @template_dir = File.dirname Ditz::find_ditz_file("share/ditz/index.rhtml") > + @template_dir = File.dirname Ditz::find_ditz_file("../share/ditz/index.rhtml") > > Was something not working? Can I change it back? The behavior should > be identical... The gem was not working for me, the root dir seems to not be in path, but lib is. That's why ../ make it works for me. > 2. The problem with storing the label objects in project.yaml is that if > two people both add a label, that file will conflict. So I think it > would be better to recreate the Label objects on the fly when the > project is loaded in. Yes but but having labels as true true entities makes things safer. Since no longer can label an issue with an ill typed label. > If you do that, you might not even need to serialize the Label object > itself. Components, releases, etc are just stored as strings in issue > objects, which makes the YAML easier to read and modify. That part makes sense, I will try to serialize them as strings. > (Components and releases are scheduled to move out of project.yaml > too---see issue 80c02356). Does my argument on checking against valid components/releases/labels makes sense to you? > 3. I'd prefer add-label instead of new-label, in line with add-release, > add-component, etc. Even better would be to just drop that step > entirely, and have 'ditz label' autocreate the label. Yes I got the idea, but auto creation have the issue mentioned before. BTW there is one more thing against this step, the set of releases/components/labels is harder to get, you have to take all issues in account to know them. The new-label instead of add-label was to avoid confusion, because add-label could mean "add a label on an issue". Best regards, -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: not available URL: From nicolas.pouillard at gmail.com Wed Sep 3 04:29:49 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Wed, 03 Sep 2008 10:29:49 +0200 Subject: [ditz-talk] What about labels? In-Reply-To: <20080902202447.GC18623@cgarbs.de> References: <1209744474-sup-3166@ausone.local> <1211686071-sup-8952@south> <1211723397-sup-238@ausone.local> <1220269476-sup-5553@guest-rocq-135070.inria.fr> <20080901175320.GB11586@cgarbs.de> <1220294435-sup-2512@ausone.local> <20080902202447.GC18623@cgarbs.de> Message-ID: <1220430140-sup-9455@ausone.inria.fr> Excerpts from Christian Garbs's message of Tue Sep 02 22:24:47 +0200 2008: > On Mon, Sep 01, 2008 at 08:41:49PM +0200, Nicolas Pouillard wrote: > > Excerpts from Christian Garbs's message of Mon Sep 01 19:53:20 +0200 2008: > > > > I don't really get what labels are. How do they compare to tags > > > for example? > > > They are the same thing, this term was chosen by gmail, and reused > > by sup, so I keep this one. > > Tags/Labels are useful, I think. > > They could supersede components or the task/bug/issue type. > One could also think of using tags like 'wontfix', 'security' or > 'wishlist' like with the Debian bugs. Right (except for wontfix that is a status and already supported to close an issue). > > > Will they be like tags but removing the "primary key" of the bugs? > > > In some way that's it. > > I don't think I'd like that :-) > > I like to have a unique identifier for an issue - even when it is a > slowly-changing thing like the current ditz ids. While the real ID is > the long unique issue id, it's impractical because it is too long > to type. Something like "ditz-10" is easy to remember and use. There is two things to don't confuse, the first one is about to enable labels (as a plugin), the second is to remove components and types. > If you remove the short issue id and introduce tags, how would that > affect the workflow? There is a decision to make when removing components: - use just the short id: @10 - use the project name only: ditz-10 - use the first label: backend-10, gui-42, wiki-21 - use all labels: bug-backend-10, feature-gui-42, task-wiki-21 I think that the first one is the current direction. > Currently I look at the ditz todos, choose an id (say, ditz-10) and > then do "ditz start ditz-10". > > If I only have labels instead of this id, what will ditz todo show? > Will an issue be listed five times if it has five labels? > With which id will it be listed if it has now label at all? Only once without labels for now, but when the todo view will be extensible one could add them. > Could you provide a fake "screenshot" of a label-enabled output of > "ditz todo"? For now it's the same as before: 0.6 (unreleased): > ditz-90: allow model object post-deserialization validation _ ditz-32: extended help for commands _ ditz-59: remove "references" But it could become: 0.6 (unreleased): > @90: allow model object post-deserialization validation _ @32: extended help for commands _ @59: remove "references" Or even: 0.6 (unreleased): > @90(tag1,tag2): allow model object post-deserialization validation _ @32(): extended help for commands _ @59(tag3): remove "references" Best regards, -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From nicolas.pouillard at gmail.com Wed Sep 3 04:38:02 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Wed, 03 Sep 2008 10:38:02 +0200 Subject: [ditz-talk] command line ditz In-Reply-To: <1220407631-sup-4112@entry> References: <1219412567.7581.2.camel@dcalford-laptop.corp.distributel.ca> <1219624940-sup-6459@entry> <1219668763.7205.1.camel@dcalford-laptop.corp.distributel.ca> <1219861183-sup-3519@entry> <1219933131.7045.5.camel@dcalford-laptop.corp.distributel.ca> <1219946903-sup-9253@entry> <1219965554-sup-9881@entry> <1220374762.21020.3.camel@dcalford-laptop.corp.distributel.ca> <1220407631-sup-4112@entry> Message-ID: <1220431013-sup-7853@ausone.inria.fr> Excerpts from William Morgan's message of Wed Sep 03 04:14:02 +0200 2008: > Reformatted excerpts from Dalton Calford's message of 2008-09-02: > > I have pulled down the latest version of ditz, git and sheila. > > > > What I don't understand is how they all work together. > > > > Is sheila a plugin? Is sheila called by ditz html to generate a > > different html page? How is sheila called/invoked in order to test > > it's output? > > Sheila is a Camping app, so you have to run it via the (latest git > version) of Camping. If you run it from anywhere in your Ditz project, > it will bring up its own server on port 3301. It uses webrick as the web > server by default; you may want to install mongrel instead. > > Here's how to run it: > > 1. Make a new clone of the project you want to track bugs with. > 2. Clone ditz from git://gitorious.org/ditz/mainline.git. > 3. Clone camping from git://github.com/why/camping.git. > 4. Clone sheila from git://github.com/wmorgan/sheila.git. > 5. Within your project dir, run: > ruby -I$CAMPING_ROOT/lib -I$DITZ_ROOT/lib -rubygems $CAMPING_ROOT/bin/camping $SHEILA_ROOT/sheila.rb > where the environment variables have been set to the clone dirs > above. I didn't look at the code to see what is the problem but here is a backtrace :) No pressure it was just to try... # loading plugins from ./.ditz-plugins # loading plugin "git" from /Users/ertai/wgit/dev-util/ditz/lib/ditz/plugins/git.rb # loading plugin "issue-claiming" from /Users/ertai/wgit/dev-util/ditz/lib/ditz/plugins/issue-claiming.rb # loading config from ../../../.ditz-config /Users/ertai/wgit/dev-ruby/sheila/sheila.rb:44:in `join': can't convert nil into String (TypeError) from /Users/ertai/wgit/dev-ruby/sheila/sheila.rb:44:in `create' from /Users/ertai/wgit/dev-ruby/camping/bin/../lib/camping/reloader.rb:82:in `load_app' from /Users/ertai/wgit/dev-ruby/camping/bin/../lib/camping/reloader.rb:40:in `initialize' from /Users/ertai/wgit/dev-ruby/camping/bin/../lib/camping/server.rb:132:in `new' from /Users/ertai/wgit/dev-ruby/camping/bin/../lib/camping/server.rb:132:in `insert_app' from /Users/ertai/wgit/dev-ruby/camping/bin/../lib/camping/server.rb:33:in `add_app' from /Users/ertai/wgit/dev-ruby/camping/bin/../lib/camping/server.rb:22:in `initialize' from /Users/ertai/wgit/dev-ruby/camping/bin/../lib/camping/server.rb:22:in `each' from /Users/ertai/wgit/dev-ruby/camping/bin/../lib/camping/server.rb:22:in `initialize' from /Users/ertai/wgit/dev-ruby/camping/bin/camping:98:in `new' from /Users/ertai/wgit/dev-ruby/camping/bin/camping:98 -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From matt at tplus1.com Wed Sep 3 09:30:57 2008 From: matt at tplus1.com (Matthew Wilson) Date: Wed, 3 Sep 2008 09:30:57 -0400 Subject: [ditz-talk] undefined method 'name' NoMethodError In-Reply-To: <1220408065-sup-9172@entry> References: <1220368782-sup-8058@entry> <1220408065-sup-9172@entry> Message-ID: First of all, thanks for replying even though I forgot to send it to the list. Second, I purged my git clone, then installed the gem, and now everything works. I apologize for eating up brain cycles. Matt On Tue, Sep 2, 2008 at 10:17 PM, William Morgan wrote: > Reformatted excerpts from Matthew Wilson's message of 2008-09-02: >> In your transcript, you got asked about tracking issues across a >> project or by component. I just immediately got prompted for a >> component. > > That is so weird. I literally cannot imagine what would cause that kind > of behavior. > >> $ ditz init >> I wasn't able to find a configuration file ./.ditz-config. >> We'll set it up right now. >> Your name (enter for "Matthew Wilson"): >> Your email address (enter for "matt at sprout.tplus1.com"): matt at tplus1.com >> Directory to store issues state in (enter for "bugs"): >> Project name (enter for "ditzfun"): >> Components: > > Wtf! > > Just for kicks, does the same thing happen with the latest git HEAD? > You can just git clone git://gitorious.org/ditz/mainline.git and run > "ruby bin/ditz" to try. > -- > William > -- Matthew Wilson matt at tplus1.com http://tplus1.com 216-470-6058 From nicolas.pouillard at gmail.com Wed Sep 3 10:08:30 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Wed, 03 Sep 2008 16:08:30 +0200 Subject: [ditz-talk] What about labels? In-Reply-To: <1220411598-sup-8575@entry> References: <1209744474-sup-3166@ausone.local> <1211686071-sup-8952@south> <1211723397-sup-238@ausone.local> <1220269476-sup-5553@guest-rocq-135070.inria.fr> <1220293541-sup-6463@entry> <1220294884-sup-1467@ausone.local> <1220319784-sup-2457@entry> <1220344497-sup-2516@guest-rocq-135070.inria.fr> <1220385412-sup-7300@ausone.local> <1220411598-sup-8575@entry> Message-ID: <1220450800-sup-8530@ausone.inria.fr> Excerpts from William Morgan's message of Wed Sep 03 05:23:55 +0200 2008: > Reformatted excerpts from nicolas.pouillard's message of 2008-09-02: > > Well, I've sent two merge requests. The first one is about to fix some > > recent bugs in ditz found while testing labels, and an addition. The > > second add the plugin for labels. > > I've merged them in. Thanks, good stuff. (I actually just committed the > same fix as your e008483d). A couple comments: > > 1. What was the point of: > - @template_dir = File.dirname Ditz::find_ditz_file("share/ditz/index.rhtml") > + @template_dir = File.dirname Ditz::find_ditz_file("../share/ditz/index.rhtml") > > Was something not working? Can I change it back? The behavior should > be identical... > > 2. The problem with storing the label objects in project.yaml is that if > two people both add a label, that file will conflict. So I think it > would be better to recreate the Label objects on the fly when the > project is loaded in. OK, no problem about recreating the object, but I want declared labels to be stored on disk. > > If you do that, you might not even need to serialize the Label object > itself. Components, releases, etc are just stored as strings in issue > objects, which makes the YAML easier to read and modify. > > (Components and releases are scheduled to move out of project.yaml > too---see issue 80c02356). OK, once this issue (80c02356) is fixed, I will do the same for labels. -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From wmorgan-ditz at masanjin.net Wed Sep 3 23:34:29 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Wed, 03 Sep 2008 20:34:29 -0700 Subject: [ditz-talk] command line ditz In-Reply-To: <1220431013-sup-7853@ausone.inria.fr> References: <1219412567.7581.2.camel@dcalford-laptop.corp.distributel.ca> <1219624940-sup-6459@entry> <1219668763.7205.1.camel@dcalford-laptop.corp.distributel.ca> <1219861183-sup-3519@entry> <1219933131.7045.5.camel@dcalford-laptop.corp.distributel.ca> <1219946903-sup-9253@entry> <1219965554-sup-9881@entry> <1220374762.21020.3.camel@dcalford-laptop.corp.distributel.ca> <1220407631-sup-4112@entry> <1220431013-sup-7853@ausone.inria.fr> Message-ID: <1220499068-sup-9416@entry> Reformatted excerpts from nicolas.pouillard's message of 2008-09-03: > I didn't look at the code to see what is the problem but here is a backtrace :) > No pressure it was just to try... > > # loading plugins from ./.ditz-plugins > # loading plugin "git" from > /Users/ertai/wgit/dev-util/ditz/lib/ditz/plugins/git.rb > # loading plugin "issue-claiming" from > /Users/ertai/wgit/dev-util/ditz/lib/ditz/plugins/issue-claiming.rb > # loading config from ../../../.ditz-config > /Users/ertai/wgit/dev-ruby/sheila/sheila.rb:44:in `join': can't convert nil > into String (TypeError) I bet that ../../../.ditz-config is doesn't have an issue_dir: field. If that's right, you should run 'ditz reconfigure' and press enter until it quits. -- William From wmorgan-ditz at masanjin.net Wed Sep 3 23:49:01 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Wed, 03 Sep 2008 20:49:01 -0700 Subject: [ditz-talk] command line ditz In-Reply-To: <1220446045.6897.5.camel@dcalford-laptop.corp.distributel.ca> References: <1219412567.7581.2.camel@dcalford-laptop.corp.distributel.ca> <1219624940-sup-6459@entry> <1219668763.7205.1.camel@dcalford-laptop.corp.distributel.ca> <1219861183-sup-3519@entry> <1219933131.7045.5.camel@dcalford-laptop.corp.distributel.ca> <1219946903-sup-9253@entry> <1219965554-sup-9881@entry> <1220374762.21020.3.camel@dcalford-laptop.corp.distributel.ca> <1220407631-sup-4112@entry> <1220446045.6897.5.camel@dcalford-laptop.corp.distributel.ca> Message-ID: <1220499277-sup-918@entry> Reformatted excerpts from Dalton Calford's message of 2008-09-03: > Is there a reason you took this particular path? > It does not seem well suited for portability or scalability. Someone else wrote Sheila. I just updated it to work with modern ditzes. > For example, my server will have between 620-700 projects on it. > We are not a company providing git services, this is just for our > internal projects. > We currently run Apache2 on the server for our existing web interface > and we would need to run over 600 dedicated to port servers in addition? No, you would have to modify Sheila so that it could handle multiple projects. But frankly Sheila is kind of a proof of concept. Given what you're trying to accomplish (namely, host a lot of git projects and put a web interface on them and also have issue tracking), I suggest using Sheila as a reference for how to add Ditz support to something like Gitorious. > I am wondering if it would be better for me to look at gitorious as it's > code is also gpl and it could perhaps support the front and and the > issue database. > One solution would cover both needs, and would cut overall development > time. > It is also written in ruby so the code should be portable to the new > system. Gitorious would be a good option for what you're trying to do. It doesn't have issue tracking, so you will have to add that. > Is anyone here familiar with Gitorious's source code? I am currently > downloading and installing it. You're going to have to reply to all if you want to ask anyone besides me. :) I'm cc'ing the list in this reply. Personally I'd be interested in adding Ditz support to Gitorious, and there is actually already an issue for this (@79149547), but it's not super high priority ATM. -- William From wmorgan-ditz at masanjin.net Wed Sep 3 23:50:27 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Wed, 03 Sep 2008 20:50:27 -0700 Subject: [ditz-talk] undefined method 'name' NoMethodError In-Reply-To: References: <1220368782-sup-8058@entry> <1220408065-sup-9172@entry> Message-ID: <1220500157-sup-7929@entry> Reformatted excerpts from Matthew Wilson's message of 2008-09-03: > Second, I purged my git clone, then installed the gem, and now > everything works. I apologize for eating up brain cycles. Someone else just reported this too... it's weird that purging the git copy had any effect because the backtrace you gave was running entirely from the gem. -- William From wmorgan-ditz at masanjin.net Wed Sep 3 23:55:14 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Wed, 03 Sep 2008 20:55:14 -0700 Subject: [ditz-talk] What about labels? In-Reply-To: <1220430140-sup-9455@ausone.inria.fr> References: <1209744474-sup-3166@ausone.local> <1211686071-sup-8952@south> <1211723397-sup-238@ausone.local> <1220269476-sup-5553@guest-rocq-135070.inria.fr> <20080901175320.GB11586@cgarbs.de> <1220294435-sup-2512@ausone.local> <20080902202447.GC18623@cgarbs.de> <1220430140-sup-9455@ausone.inria.fr> Message-ID: <1220500338-sup-9391@entry> Reformatted excerpts from nicolas.pouillard's message of 2008-09-03: > There is a decision to make when removing components: > - use just the short id: @10 > - use the project name only: ditz-10 > - use the first label: backend-10, gui-42, wiki-21 > - use all labels: bug-backend-10, feature-gui-42, task-wiki-21 > > I think that the first one is the current direction. Yeah. What I'm currently thinking is that if/when components get moved into a plugin, the Ditz official standard issue names will be of the @10 form, and the component plugin will provide the ability to revert to the per-component naming scheme. -- William From wmorgan-ditz at masanjin.net Thu Sep 4 00:02:52 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Wed, 03 Sep 2008 21:02:52 -0700 Subject: [ditz-talk] What about labels? In-Reply-To: <1220429713-sup-6202@ausone.inria.fr> References: <1209744474-sup-3166@ausone.local> <1211686071-sup-8952@south> <1211723397-sup-238@ausone.local> <1220269476-sup-5553@guest-rocq-135070.inria.fr> <1220293541-sup-6463@entry> <1220294884-sup-1467@ausone.local> <1220319784-sup-2457@entry> <1220344497-sup-2516@guest-rocq-135070.inria.fr> <1220385412-sup-7300@ausone.local> <1220411598-sup-8575@entry> <1220429713-sup-6202@ausone.inria.fr> Message-ID: <1220500520-sup-1286@entry> Reformatted excerpts from nicolas.pouillard's message of 2008-09-03: > Does my argument on checking against valid components/releases/labels > makes sense to you? Yes. It's a different way of thinking about labels than I had, but that's fine. In your world labels don't change very often, so it's ok have them in project.yaml and to be strict about validating them. > The new-label instead of add-label was to avoid confusion, because > add-label could mean "add a label on an issue". Ok, makes sense. -- William From nicolas.pouillard at gmail.com Thu Sep 4 09:34:26 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Thu, 04 Sep 2008 15:34:26 +0200 Subject: [ditz-talk] command line ditz In-Reply-To: <1220499068-sup-9416@entry> References: <1219412567.7581.2.camel@dcalford-laptop.corp.distributel.ca> <1219624940-sup-6459@entry> <1219668763.7205.1.camel@dcalford-laptop.corp.distributel.ca> <1219861183-sup-3519@entry> <1219933131.7045.5.camel@dcalford-laptop.corp.distributel.ca> <1219946903-sup-9253@entry> <1219965554-sup-9881@entry> <1220374762.21020.3.camel@dcalford-laptop.corp.distributel.ca> <1220407631-sup-4112@entry> <1220431013-sup-7853@ausone.inria.fr> <1220499068-sup-9416@entry> Message-ID: <1220534026-sup-8102@ausone.inria.fr> Excerpts from William Morgan's message of Thu Sep 04 05:34:29 +0200 2008: > Reformatted excerpts from nicolas.pouillard's message of 2008-09-03: > > I didn't look at the code to see what is the problem but here is a backtrace :) > > No pressure it was just to try... > > > > # loading plugins from ./.ditz-plugins > > # loading plugin "git" from > > /Users/ertai/wgit/dev-util/ditz/lib/ditz/plugins/git.rb > > # loading plugin "issue-claiming" from > > /Users/ertai/wgit/dev-util/ditz/lib/ditz/plugins/issue-claiming.rb > > # loading config from ../../../.ditz-config > > /Users/ertai/wgit/dev-ruby/sheila/sheila.rb:44:in `join': can't convert nil > > into String (TypeError) > > I bet that ../../../.ditz-config is doesn't have an issue_dir: field. > If that's right, you should run 'ditz reconfigure' and press enter until > it quits. Hum that right, my .ditz-config don't have an issue_dir: field and ditz reconfigure added it. But I still get an error until I copy the .ditz-config in the project directory. In that case it seems to works! Great! That sound a bit strange for me, since the .ditz-config is in my $HOME, and the ditz bugs directory is obviously not there. -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: not available URL: From matt at tplus1.com Thu Sep 4 12:45:47 2008 From: matt at tplus1.com (Matthew Wilson) Date: Thu, 4 Sep 2008 12:45:47 -0400 Subject: [ditz-talk] ditz html generates html in current directory, not next to bugs folder Message-ID: So, I got so used to using ditz commands inside of subdirectories of my project that I ran ditz html while I was way down in the tree. So, ditz dutifully made an html folder right there. I didn't pay attention to the output of the command. Instead I just reloaded my browser view of the html folder at the top of my tree and thought "Hmm; ditz didn't rewrite these pages." It took me a few minutes to figure out what happened. Would it be worthwhile to force ditz to always put the html stuff in the same spot rather than the current directory? Matt -- Matthew Wilson matt at tplus1.com http://tplus1.com 216-470-6058 From wmorgan-ditz at masanjin.net Wed Sep 10 16:47:53 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Wed, 10 Sep 2008 13:47:53 -0700 Subject: [ditz-talk] ditz html generates html in current directory, not next to bugs folder In-Reply-To: References: Message-ID: <1221079259-sup-4814@entry> Reformatted excerpts from Matthew Wilson's message of 2008-09-04: > Would it be worthwhile to force ditz to always put the html stuff in > the same spot rather than the current directory? I think that would conflict with my expectations. Also note it does print out the location of the directory it created (granted, in URL form). -- William From nichols7 at googlemail.com Thu Sep 11 12:41:20 2008 From: nichols7 at googlemail.com (Thomas Nichols) Date: Thu, 11 Sep 2008 17:41:20 +0100 Subject: [ditz-talk] sorting todo lists Message-ID: <48C94A30.7010606@googlemail.com> Hi, We built an ad-hoc system around ditz, using 'todotxt'-style tags in the title -- e.g: @prio=10 @thomas - fix export_as_zip for empty datasets This allowed me to do `ditz todo Etna` to list all tasks for release Etna, then use a delightful mash of grep and sort to list *my* tasks, sorted by priority. This was a hideous hack, but it worked (though shuffling priorities is a PITA). It means I can follow a GTD-style workflow -- when I'm coding, the current task is right there at the top of the list, I can see what I have planned next Now I'm wondering how to get that ability to sort and filter my tasklist using plugins. I've seen issue 3e079c58 at http://ditz.rubyforge.org/ditz/issue-3e079c58deadcc32fd1f78782c924324d29e4cdf.html but I'm not sure what's envisaged for this. If I add a new 'priority' field, what's the best way to get 'ditz todo' to sort the list by priority? Am I best monkey-patching Operator and defining todo_list_by_priority, or is there an approach based on Hooks / plugins I haven't fathomed yet? I've also got the latest github ditz / sheila / camping code set up, and with the addition of edit/start/close/comment actions this could be very useful -- but from recent comments I'm not sure whether there are plans to add such support. Any thoughts on extending Sheila to handle fields defined by plugins? I'm not going to get much time on any of this for the next few weeks, so atm I'm just trawling for ideas... Regards, Thomas. From wmorgan-ditz at masanjin.net Fri Sep 12 12:43:09 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Fri, 12 Sep 2008 09:43:09 -0700 Subject: [ditz-talk] sorting todo lists In-Reply-To: <48C94A30.7010606@googlemail.com> References: <48C94A30.7010606@googlemail.com> Message-ID: <1221236861-sup-3279@entry> Hi Thomas, Reformatted excerpts from Thomas Nichols's message of 2008-09-11: > Now I'm wondering how to get that ability to sort and filter my tasklist > using plugins. I've seen issue 3e079c58 at > http://ditz.rubyforge.org/ditz/issue-3e079c58deadcc32fd1f78782c924324d29e4cdf.html > but I'm not sure what's envisaged for this. If I add a new 'priority' > field, what's the best way to get 'ditz todo' to sort the list by > priority? Am I best monkey-patching Operator and defining > todo_list_by_priority, or is there an approach based on Hooks / > plugins I haven't fathomed yet? In this particular case, I will probably add a sort_order field to Issue, modify Operator#todo_list_for to use it, and the priority plugin will be monkey-patching that method. But yes, that's the general technique for plugins: monkey-patch to add (and occasionally modify) methods and fields in ModelObject subclasses, and methods in Operator. The trick is to restructure the base Ditz classes in such a way that the monkey-patching is minimized. Allowing plugins to modify the todo list output, for example, is something I need to find a nice clean way to do. > I've also got the latest github ditz / sheila / camping code set up, and > with the addition of edit/start/close/comment actions this could be very > useful -- but from recent comments I'm not sure whether there are plans > to add such support. Any thoughts on extending Sheila to handle fields > defined by plugins? My immediate plans for Sheila are to make it a simple web interface for public, non-developer bug reports, so it will probably only support adding of issues and comments, and little else. The intention is to support what I think will be the common case for projects using ditz: you want to lower the bar for user-generated bug reports by providing a web interface, but developers will mostly work through the ditz commandline, and that's how they'll triage, resolve, and edit issues. Of course it's possible to have a more full-fledged web interface with logins, issue modification, and all that stuff, but that gets more complicated, so I'm envisioning that being further down the road. I have to be careful not to start building JIRA. -- William From nolan at thewordnerd.info Fri Sep 12 13:00:48 2008 From: nolan at thewordnerd.info (Nolan Darilek) Date: Fri, 12 Sep 2008 12:00:48 -0500 Subject: [ditz-talk] Some Ditz thoughts Message-ID: <48CAA040.6060009@thewordnerd.info> Hey, folks. I've been hacking on Ditz for the past few weeks and had a few thoughts I wanted to put out. Hacking time over the next 1.5 months is going to be pretty limited, so I don't think I'll be able to get to these anytime soon, but if no one runs with them then I likely will eventually. :) Has anyone considered changing the name of the default ditz directory from bugs to something like .ditz? I like the idea of putting project metadata--version control, issue-tracking, etc.--into hidden .directories. Also, Ditz isn't just for bugs, so having a bugs directory storing issues seems like a bit of a misnomer. :) Also, this correctly identifies what program is needed to affect the issue metadata. If I check out a project containing a bugs directory, I have to dig around a bit to determine how it is maintained. If my project contains a .ditz dir, though, that makes it a bit easier for new developers to google the needed tool. I know this is currently possible via project configs, it just seems like it might be a more sensible default. Speaking of project configs, I like the idea of per-user and per-project configuration. Perhaps it could work like git's config system--create a config operator with a --global flag, merging project and global defaults, though I could see a few problems with this scenario. I'd like to store a global email address as well as specific addresses per project, though project-specific email addresses should probably be stored in the global configuration file to prevent one person from accidentally changing and committing the project-specific config. Just wondering if anyone had given this issue any thought? I was also pondering the merging of standard and plugin config such that there is only one file with a plugins: section. It'd be a hash with the plugin name as key and a hash of config values for each plugin. This would make removing a plugin and its config a snap, both programatically and via the editor. Anyhow, just a few thoughts. I'm sorry that I lack the time to work on these just now, but perhaps they'll inspire someone else. :) From matt at tplus1.com Fri Sep 12 13:19:22 2008 From: matt at tplus1.com (Matthew Wilson) Date: Fri, 12 Sep 2008 13:19:22 -0400 Subject: [ditz-talk] Some Ditz thoughts In-Reply-To: <48CAA040.6060009@thewordnerd.info> References: <48CAA040.6060009@thewordnerd.info> Message-ID: On Fri, Sep 12, 2008 at 1:00 PM, Nolan Darilek wrote: > Has anyone considered changing the name of the default ditz directory from > bugs to something like .ditz? I like the idea of putting project > metadata--version control, issue-tracking, etc.--into hidden .directories. > Also, Ditz isn't just for bugs, so having a bugs directory storing issues > seems like a bit of a misnomer. :) Also, this correctly identifies what > program is needed to affect the issue metadata. If I check out a project > containing a bugs directory, I have to dig around a bit to determine how it > is maintained. If my project contains a .ditz dir, though, that makes it a > bit easier for new developers to google the needed tool. I know this is > currently possible via project configs, it just seems like it might be a > more sensible default. +1 on this. Matt From matt at tplus1.com Tue Sep 16 13:49:32 2008 From: matt at tplus1.com (Matthew Wilson) Date: Tue, 16 Sep 2008 13:49:32 -0400 Subject: [ditz-talk] It would be nice if /edit could be a user default Message-ID: I prefer using /edit to write my issues. Is there any way to make that the default, so that ditz immediately opens my $EDITOR? Matt -- Matthew Wilson matt at tplus1.com http://tplus1.com From wmorgan-ditz at masanjin.net Tue Sep 16 14:29:18 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Tue, 16 Sep 2008 11:29:18 -0700 Subject: [ditz-talk] It would be nice if /edit could be a user default In-Reply-To: References: Message-ID: <1221589736-sup-5127@entry> Reformatted excerpts from Matthew Wilson's message of 2008-09-16: > I prefer using /edit to write my issues. Is there any way to make > that the default, so that ditz immediately opens my $EDITOR? This will be the default in 0.6. See issue b568fb68. -- William From shramov at mexmat.net Tue Sep 16 14:45:04 2008 From: shramov at mexmat.net (Pavel Shramov) Date: Tue, 16 Sep 2008 22:45:04 +0400 Subject: [ditz-talk] todo in iCalendar format Message-ID: <20080916184502.GA7571@lebu.psha.org.ru> Proposed patch adds todo_ics command which dumps full todo list in ics format. It uses VPim [1] to format data so this library is required if you want to use this feature. Output was tested with KDE and some custom tools based on python-icalendar. Pavel -- [1] http://vpim.rubyforge.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Export-todo-list-in-iCalendar-format.patch Type: text/x-diff Size: 2220 bytes Desc: not available URL: From shramov at mexmat.net Tue Sep 16 15:19:01 2008 From: shramov at mexmat.net (Pavel Shramov) Date: Tue, 16 Sep 2008 23:19:01 +0400 Subject: [ditz-talk] todo in iCalendar format In-Reply-To: <20080916184502.GA7571@lebu.psha.org.ru> References: <20080916184502.GA7571@lebu.psha.org.ru> Message-ID: <20080916191901.GA8695@lebu.psha.org.ru> On Tue, Sep 16, 2008 at 10:45:04PM +0400, Pavel Shramov wrote: > Proposed patch adds todo_ics command which dumps full todo list in ics ... Sorry for buggy patch, bugfix attached. Used C/python style of tests when zero value is false... Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-division-by-zero-error-when-issues.length-0.patch Type: text/x-diff Size: 902 bytes Desc: not available URL: From shramov at mexmat.net Tue Sep 16 16:01:51 2008 From: shramov at mexmat.net (Pavel Shramov) Date: Wed, 17 Sep 2008 00:01:51 +0400 Subject: [ditz-talk] [PATCH] Fix done/not done behaviour In-Reply-To: <20080916191901.GA8695@lebu.psha.org.ru> References: <20080916191901.GA8695@lebu.psha.org.ru> Message-ID: <1221595311-10730-1-git-send-email-shramov@mexmat.net> From: Pavel Shramov PERCENT-DONE is set to 100 only when release is released otherwise it has maximum of 99 --- lib/ditz/operator.rb | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/lib/ditz/operator.rb b/lib/ditz/operator.rb index e428ac2..1fe6d90 100644 --- a/lib/ditz/operator.rb +++ b/lib/ditz/operator.rb @@ -357,8 +357,9 @@ EOS releases.each do |r| issues = project.issues_for_release r done = 0 - done = (100 * (issues.select { |i| i.closed? }).length / issues.length).to_int if issues.length != 0 + done = (99 * (issues.select { |i| i.closed? }).length / issues.length).to_int if issues.length != 0 if r != :unassigned + done = 100 if r.released? parent = "release-#{r.hash}" title = "Release #{r.name} (#{r.status})" else -- 1.5.6.3 From matt at tplus1.com Fri Sep 19 09:39:55 2008 From: matt at tplus1.com (Matthew Wilson) Date: Fri, 19 Sep 2008 09:39:55 -0400 Subject: [ditz-talk] Using ditz with procmail? Message-ID: My non-technical colleagues are unlikely to learn how to use command-line ditz. I'd like to tell them just to send me emails formatted in a certain way, and then I want to write a procmail script that parses the email and instantly creates an issue. Has anyone else already done something like this? Matt -- Matthew Wilson matt at tplus1.com http://tplus1.com 216-470-6058 From wmorgan-ditz at masanjin.net Fri Sep 19 12:46:26 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Fri, 19 Sep 2008 09:46:26 -0700 Subject: [ditz-talk] Using ditz with procmail? In-Reply-To: References: Message-ID: <1221842753-sup-8446@entry> Reformatted excerpts from Matthew Wilson's message of 2008-09-19: > I'd like to tell them just to send me emails formatted in a certain > way, and then I want to write a procmail script that parses the email > and instantly creates an issue. > > Has anyone else already done something like this? It'd certainly be possible, but wouldn't it be easier to try and set up sheila so that they can file issues via the web? -- William From wmorgan-ditz at masanjin.net Fri Sep 19 12:48:15 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Fri, 19 Sep 2008 09:48:15 -0700 Subject: [ditz-talk] todo in iCalendar format In-Reply-To: <20080916184502.GA7571@lebu.psha.org.ru> References: <20080916184502.GA7571@lebu.psha.org.ru> Message-ID: <1221842846-sup-5760@entry> Reformatted excerpts from Pavel Shramov's message of 2008-09-16: > Proposed patch adds todo_ics command which dumps full todo list in ics > format. It uses VPim [1] to format data so this library is required if > you want to use this feature. Thanks. I like this a lot. Would be you able to package it as a plugin, though? It should only require a few lines of changes. -- William From shramov at mexmat.net Fri Sep 19 16:36:32 2008 From: shramov at mexmat.net (Pavel Shramov) Date: Sat, 20 Sep 2008 00:36:32 +0400 Subject: [ditz-talk] [PATCH] Added icalendar plugin In-Reply-To: <1221842846-sup-5760@entry> References: <1221842846-sup-5760@entry> Message-ID: <1221856592-9755-1-git-send-email-shramov@mexmat.net> From: Pavel Shramov Plugin adds todo-ics command to export full todo in iCalendar (RFC 2445) format Signed-off-by: Pavel Shramov --- lib/ditz/plugins/icalendar.rb | 64 +++++++++++++++++++++++++++++++++++++++++ 1 files changed, 64 insertions(+), 0 deletions(-) create mode 100644 lib/ditz/plugins/icalendar.rb diff --git a/lib/ditz/plugins/icalendar.rb b/lib/ditz/plugins/icalendar.rb new file mode 100644 index 0000000..408b014 --- /dev/null +++ b/lib/ditz/plugins/icalendar.rb @@ -0,0 +1,64 @@ +## icalendar ditz plugin +## +## This plugin adds ability to export full todo list in iCalendar (RFC 2445) format. +## It is useful for integration with different pim software like KOrganizer. +## +## Issues are converted to VTODO entries with completion status set to 50 if +## its state is :in_progress, 100 if it's closed and 0 otherwise. +## Progress for release is 100 if it's released otherwise it's 99 * closed/all +## issues. So maximum for active release is 99 and it's not shown as done until +## released. +## +## Commands added: +## ditz todo-ics: set the git branch of an issue +## +## Usage: +## 1. add a line "- icalendar" to the .ditz-plugins file in the project root + +require 'vpim/icalendar' + +module Ditz + +class Operator + operation :todo_ics, "Generate full todo list in iCalendar format", :maybe_release + def todo_ics project, config, releases + cal = Vpim::Icalendar.create + releases ||= project.releases + [:unassigned] + releases = [*releases] + releases.each do |r| + issues = project.issues_for_release r + done = 0 + done = (99 * (issues.select { |i| i.closed? }).length / issues.length).to_int if issues.length != 0 + if r != :unassigned + done = 100 if r.released? + parent = "release-#{r.hash}" + title = "Release #{r.name} (#{r.status})" + else + parent = "release-unassigned" + title = "Unassigned" + end + cal.push Vpim::Icalendar::Vtodo.create("SUMMARY" => title, "UID" => parent, "PERCENT-COMPLETE" => "#{done}") + issues.each do |i| + cal.push todo2vtodo(i, parent) + end + end + puts cal.encode + end + + def todo2vtodo todo, parent + h = {"SUMMARY" => "#{todo.title}", "UID" => "#{todo.type}-#{todo.id}"} + h["RELATED-TO"] = parent if parent + h["PRIORITY"] = "3" if todo.type == :bugfix + h["PERCENT-COMPLETE"] = case todo.status + when :closed + "100" + when :in_progress + "50" + else + "0" + end + return Vpim::Icalendar::Vtodo.create(h) + end +end + +end -- 1.5.6.5 From wmorgan-ditz at masanjin.net Fri Sep 19 20:33:29 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Fri, 19 Sep 2008 17:33:29 -0700 Subject: [ditz-talk] [PATCH] Added icalendar plugin In-Reply-To: <1221856592-9755-1-git-send-email-shramov@mexmat.net> References: <1221842846-sup-5760@entry> <1221856592-9755-1-git-send-email-shramov@mexmat.net> Message-ID: <1221870792-sup-7964@entry> Reformatted excerpts from Pavel Shramov's message of 2008-09-19: > From: Pavel Shramov > > Plugin adds todo-ics command to export full todo in iCalendar (RFC > 2445) format Added, thanks! Scheduled for 0.6. -- William From wmorgan-ditz at masanjin.net Mon Sep 29 22:24:21 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Mon, 29 Sep 2008 19:24:21 -0700 Subject: [ditz-talk] Some Ditz thoughts In-Reply-To: <48CAA040.6060009@thewordnerd.info> References: <48CAA040.6060009@thewordnerd.info> Message-ID: <1222740655-sup-1322@entry> Reformatted excerpts from Nolan Darilek's message of 2008-09-12: > I was also pondering the merging of standard and plugin config such that > there is only one file with a plugins: section. It'd be a hash with the > plugin name as key and a hash of config values for each plugin. This > would make removing a plugin and its config a snap, both programatically > and via the editor. The reason they're separate is because the plugins can modify what the configuration file contains/is allowed to contain, so it has to be loaded first. Putting it in a separate file is the easiest way to accomplish that. -- William From wmorgan-ditz at masanjin.net Mon Sep 29 22:38:26 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Mon, 29 Sep 2008 19:38:26 -0700 Subject: [ditz-talk] Some Ditz thoughts In-Reply-To: References: <48CAA040.6060009@thewordnerd.info> Message-ID: <1222742187-sup-3672@entry> Reformatted excerpts from Matthew Wilson's message of 2008-09-12: > On Fri, Sep 12, 2008 at 1:00 PM, Nolan Darilek wrote: > > Has anyone considered changing the name of the default ditz > > directory from bugs to something like .ditz? > > +1 on this. I've merged in Nolan's branch to this effect. Note that you'll have to 'ditz reconfigure' and set the issue dir to .ditz for ditz, since bugs/ was renamed to .ditz/. -- William From dcalford at distributel.ca Tue Sep 30 10:34:14 2008 From: dcalford at distributel.ca (Dalton Calford) Date: Tue, 30 Sep 2008 10:34:14 -0400 Subject: [ditz-talk] Ditz on Gem ? Message-ID: <1222785254.7163.7.camel@dcalford-laptop.corp.distributel.ca> Just tried to do a gem install ditz and it can not find it. Is someone changing things again? From wmorgan-ditz at masanjin.net Tue Sep 30 13:48:52 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Tue, 30 Sep 2008 10:48:52 -0700 Subject: [ditz-talk] Ditz on Gem ? In-Reply-To: <1222785254.7163.7.camel@dcalford-laptop.corp.distributel.ca> References: <1222785254.7163.7.camel@dcalford-laptop.corp.distributel.ca> Message-ID: <1222796901-sup-5766@entry> Reformatted excerpts from Dalton Calford's message of 2008-09-30: > Just tried to do a gem install ditz and it can not find it. Seems to work for me. Is anyone else having this problem? You can always download it from RubyForge directly: http://rubyforge.org/frs/download.php/41560/ditz-0.5.gem -- William From dcalford at distributel.ca Tue Sep 30 14:18:49 2008 From: dcalford at distributel.ca (Dalton Calford) Date: Tue, 30 Sep 2008 14:18:49 -0400 Subject: [ditz-talk] Ditz on Gem ? In-Reply-To: <1222796901-sup-5766@entry> References: <1222785254.7163.7.camel@dcalford-laptop.corp.distributel.ca> <1222796901-sup-5766@entry> Message-ID: <1222798729.7163.11.camel@dcalford-laptop.corp.distributel.ca> It started working about 15 minutes after I posted on the list. Thanks anyways. On Tue, 2008-09-30 at 10:48 -0700, William Morgan wrote: > Reformatted excerpts from Dalton Calford's message of 2008-09-30: > > Just tried to do a gem install ditz and it can not find it. > > Seems to work for me. Is anyone else having this problem? > > You can always download it from RubyForge directly: > http://rubyforge.org/frs/download.php/41560/ditz-0.5.gem