From gera at theoldmonk.net  Sat Feb  7 05:56:31 2009
From: gera at theoldmonk.net (Devendra Gera)
Date: Sat, 7 Feb 2009 16:26:31 +0530
Subject: [ditz-talk] Dependencies
Message-ID: <20090207105631.GA20334@gera-laptop>

Hi,
I've been looking into distributed bug tracking systems, and found ditz
to be the only one which works (for me, at least). However, it does not
support dependencies.

There exists a bug for that though :
http://ditz.rubyforge.org/ditz/issue-ce36abcc8f40cf3ae46a369985af0afe08447cbd.html

I'm not a ruby programmer, so I thought it prudent to ask - is anyone
working on that bug? I can volunteer of course, but if there is an
existing line of thought going behind that bug, or if someone has some
design in mind, I'd like to follow that path to avoid duplicate (and
possibly inferior) effort on my part.

Even in the absence of a plan/design, any tips are welcome and would be
greatly appreciated.

Thanks,
--gera.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://rubyforge.org/pipermail/ditz-talk/attachments/20090207/d1c15afd/attachment.bin>

From wmorgan-ditz at masanjin.net  Mon Feb  9 11:38:26 2009
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Mon, 09 Feb 2009 08:38:26 -0800
Subject: [ditz-talk] Dependencies
In-Reply-To: <20090207105631.GA20334@gera-laptop>
References: <20090207105631.GA20334@gera-laptop>
Message-ID: <1234196814-sup-4577@entry>

Reformatted excerpts from Devendra Gera's message of 2009-02-07:
> I'm not a ruby programmer, so I thought it prudent to ask - is anyone
> working on that bug?

No one (AFIAK) is actively working on it. But the plugin system is
stable and it wouldn't be hard to implement this.

In terms of a design, I was thinking of something very lightweight, that
just let you add issues to a 'dependencies' field without imposing any
other real constraints (maybe warning if you try and close something
without having closed its dependencies.) In this case in would be a
pretty simple plugin.

A good model for this might be the issue-claiming plugin, which also
adds a field to the Issue class, tweaks the displays to include it,
and adds and overrides a few commands. (But the field will have to be
set :multi.)
-- 
William <wmorgan-ditz at masanjin.net>

From gera at theoldmonk.net  Mon Feb  9 13:19:43 2009
From: gera at theoldmonk.net (Devendra Gera)
Date: Mon, 9 Feb 2009 23:49:43 +0530
Subject: [ditz-talk] Dependencies
In-Reply-To: <1234196814-sup-4577@entry>
References: <20090207105631.GA20334@gera-laptop> <1234196814-sup-4577@entry>
Message-ID: <20090209181943.GA11066@gera-laptop>

On Mon, 09 Feb 2009, William Morgan wrote:

> In terms of a design, I was thinking of something very lightweight, that
> just let you add issues to a 'dependencies' field without imposing any
> other real constraints (maybe warning if you try and close something
> without having closed its dependencies.) In this case in would be a
> pretty simple plugin.

I was thinking that bugs with open dependencies wouldn't appear in a lot
of views, but now I realize that might not be entirely "correct". But
there are some views that shouldn't show bugs with open dependencies.
The TODO view is probably one of them.

Or maybe we can have a separate GTD view (show me what I can work on
_now_). Any thoughts on this?

--gera.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://rubyforge.org/pipermail/ditz-talk/attachments/20090209/c48897eb/attachment.bin>

From wmorgan-ditz at masanjin.net  Mon Feb  9 15:27:14 2009
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Mon, 09 Feb 2009 12:27:14 -0800
Subject: [ditz-talk] Dependencies
In-Reply-To: <20090209181943.GA11066@gera-laptop>
References: <20090207105631.GA20334@gera-laptop> <1234196814-sup-4577@entry>
	<20090209181943.GA11066@gera-laptop>
Message-ID: <1234210993-sup-8539@entry>

Reformatted excerpts from Devendra Gera's message of 2009-02-09:
> I was thinking that bugs with open dependencies wouldn't appear in a
> lot of views, but now I realize that might not be entirely "correct".
> But there are some views that shouldn't show bugs with open
> dependencies.  The TODO view is probably one of them.
> 
> Or maybe we can have a separate GTD view (show me what I can work on
> _now_). Any thoughts on this?

The both sound plausibly useful. Honestly, if you have a particular
itch, scratch it. The plugin system is there to accomodate everyone's
crazy desires. If someone else doesn't like the particulars, they can
make their own dependency plugin. :)
-- 
William <wmorgan-ditz at masanjin.net>

From ninja at slaphack.com  Tue Feb 10 15:53:21 2009
From: ninja at slaphack.com (David Masover)
Date: Tue, 10 Feb 2009 14:53:21 -0600
Subject: [ditz-talk] Dependencies
In-Reply-To: <1234196814-sup-4577@entry>
References: <20090207105631.GA20334@gera-laptop> <1234196814-sup-4577@entry>
Message-ID: <4991E941.4030501@slaphack.com>

William Morgan wrote:
> In terms of a design, I was thinking of something very lightweight, that
> just let you add issues to a 'dependencies' field without imposing any
> other real constraints (maybe warning if you try and close something
> without having closed its dependencies.) In this case in would be a
> pretty simple plugin.
>   

What would make such a plugin useful for me is ordering -- a view which 
only shows me things to do which have no outstanding dependencies, 
ordered by the collective priority of things depending on them, for example.

It would also be useful to have automatic resolution -- for example, 
declare an issue as strictly the result of a collection of other issues. 
When the dependencies are done, so is that issue. That's not as 
important, though, with the above in place.

This might benefit from a cache of some sort -- something which you'd 
probably add to .gitignore. But that's probably premature, at this point.

From andrea.fazzi at alcacoop.it  Sun Feb 15 10:24:19 2009
From: andrea.fazzi at alcacoop.it (Andrea Fazzi)
Date: Sun, 15 Feb 2009 16:24:19 +0100
Subject: [ditz-talk] Time spent on an issue
Message-ID: <1234711459.10305.83.camel@ganimoide>

Hi all,

I wonder if there is a way to calculate the time spent on an issue (the
sum of all time intervals between start and stop). Actually, it seems
that only the age of the issue is stored and shown. If not yet
implemented this can be a nice feature.

Thanks for the great software.
Andrea



From akaihol+ditz at ambitone.com  Sun Feb 15 15:53:00 2009
From: akaihol+ditz at ambitone.com (Antti Kaihola)
Date: Sun, 15 Feb 2009 22:53:00 +0200
Subject: [ditz-talk] Time spent on an issue
In-Reply-To: <1234711459.10305.83.camel@ganimoide>
References: <1234711459.10305.83.camel@ganimoide>
Message-ID: <20090215225300.6c0e5730@veli>

> I wonder if there is a way to calculate the time spent on an issue
> (the sum of all time intervals between start and stop). Actually, it
> seems that only the age of the issue is stored and shown. If not yet
> implemented this can be a nice feature.

I've written a Python script [1] which produces a report on work hours
spent on selected or all Ditz issues in a project. It shows both totals
as well as daily and weekly hours. You can also exclude hours before
and/or after given timestamps. The name of the script is a bit off
since I planned to add more functionality (and that might still happen).

A separate Python script is of course a hack and this would be nicer
implemented in Ditz or as a plugin. I just haven't learned Ruby yet and
wanted to use the feature immediately.

A shortcoming in using Ditz for work log tracking is that the model it
uses doesn't work when multiple people might work on the same issue and
their work hours could overlap. The status is defined per issue, not
per issue/person.

[1] http://github.com/akaihola/pyditz

From andrea.fazzi at alcacoop.it  Mon Feb 16 05:44:37 2009
From: andrea.fazzi at alcacoop.it (Andrea Fazzi)
Date: Mon, 16 Feb 2009 11:44:37 +0100
Subject: [ditz-talk] Time spent on an issue
In-Reply-To: <20090215225300.6c0e5730@veli>
References: <1234711459.10305.83.camel@ganimoide>
	<20090215225300.6c0e5730@veli>
Message-ID: <1234781077.14165.13.camel@ganimoide>

Il giorno dom, 15/02/2009 alle 22.53 +0200, Antti Kaihola ha scritto:
> A shortcoming in using Ditz for work log tracking is that the model it
> uses doesn't work when multiple people might work on the same issue
> and
> their work hours could overlap. The status is defined per issue, not
> per issue/person.

Hi Antti,

thanks for your answer.
Yes, I understand. But even if we get the total time spent on an issue
instead of a per issue/person time value it would be a useful feature
IMHO. I'd like to hear William's opinion too.

Thanks.
Andrea



From andrea.fazzi at alcacoop.it  Fri Feb 20 10:07:07 2009
From: andrea.fazzi at alcacoop.it (Andrea Fazzi)
Date: Fri, 20 Feb 2009 16:07:07 +0100
Subject: [ditz-talk] issue-timetracker plugin
Message-ID: <1235142427.9077.9.camel@ganimoide>

Hi all,

during the last week I decided to play with ditz and to write a very
simple plugin that performs time tracking on an issue. You can find the
plugin on my ditz clone on gitorious:

http://gitorious.org/projects/ditz/repos/remogatto-clone

I'd like to read your feedbacks and I'd like to know if there's some
interest in putting this stuff in the ditz mainline.

== SYNOPSIS:

ditz start issue_id # to start the timer
ditz stop issue_id # to pause the timer
ditz show issue_id # display 'Time spent' field

Regards,
Andrea



From matt at tplus1.com  Fri Feb 20 11:15:08 2009
From: matt at tplus1.com (Matthew Wilson)
Date: Fri, 20 Feb 2009 11:15:08 -0500
Subject: [ditz-talk] issue-timetracker plugin
In-Reply-To: <1235142427.9077.9.camel@ganimoide>
References: <1235142427.9077.9.camel@ganimoide>
Message-ID: <f6f643a20902200815q9330af8ta66d862401427cd3@mail.gmail.com>

Sounds neat.  But how does your start command affect the start command
already built into ditz?  Does it do everything the old one did AND
start the clock?

On Fri, Feb 20, 2009 at 10:07 AM, Andrea Fazzi <andrea.fazzi at alcacoop.it> wrote:
> Hi all,
>
> during the last week I decided to play with ditz and to write a very
> simple plugin that performs time tracking on an issue. You can find the
> plugin on my ditz clone on gitorious:
>
> http://gitorious.org/projects/ditz/repos/remogatto-clone
>
> I'd like to read your feedbacks and I'd like to know if there's some
> interest in putting this stuff in the ditz mainline.
>
> == SYNOPSIS:
>
> ditz start issue_id # to start the timer
> ditz stop issue_id # to pause the timer
> ditz show issue_id # display 'Time spent' field
>
> Regards,
> Andrea
>
>
> _______________________________________________
> ditz-talk mailing list
> ditz-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ditz-talk
>



-- 
Matthew Wilson
matt at tplus1.com
http://tplus1.com

From andrea.fazzi at alcacoop.it  Fri Feb 20 11:54:14 2009
From: andrea.fazzi at alcacoop.it (Andrea Fazzi)
Date: Fri, 20 Feb 2009 17:54:14 +0100
Subject: [ditz-talk] issue-timetracker plugin
In-Reply-To: <f6f643a20902200815q9330af8ta66d862401427cd3@mail.gmail.com>
References: <1235142427.9077.9.camel@ganimoide>
	<f6f643a20902200815q9330af8ta66d862401427cd3@mail.gmail.com>
Message-ID: <1235148854.12073.7.camel@ganimoide>

Il giorno ven, 20/02/2009 alle 11.15 -0500, Matthew Wilson ha scritto: 
> Sounds neat.  But how does your start command affect the start command
> already built into ditz?  Does it do everything the old one did AND
> start the clock?

Yes, it does. This is possible thanks to the ruby's capability to
re-open existing classes. Look at this excerpt from
issue-timetracker.rb[1]:

class Issue
  alias :old_start_work :start_work
  alias :old_stop_work :stop_work
  def start_work(who, comment)
    self.mark_time = Time.now
    old_start_work(who, comment)
  end
  def stop_work(who, comment)
    self.time_spent += Time.now - self.mark_time
    self.mark_time = Time.now
    old_stop_work(who, comment)
  end
end

The code above re-opens the class Issue, then it saves the current
start_work and stop_work methods (aliasing) and finally it redefines
those method augmenting their functionalities.

Regards,
Andrea



From andrea.fazzi at alcacoop.it  Fri Feb 20 11:58:57 2009
From: andrea.fazzi at alcacoop.it (Andrea Fazzi)
Date: Fri, 20 Feb 2009 17:58:57 +0100
Subject: [ditz-talk] issue-timetracker plugin
In-Reply-To: <1235148854.12073.7.camel@ganimoide>
References: <1235142427.9077.9.camel@ganimoide>
	<f6f643a20902200815q9330af8ta66d862401427cd3@mail.gmail.com>
	<1235148854.12073.7.camel@ganimoide>
Message-ID: <1235149137.12073.9.camel@ganimoide>

Il giorno ven, 20/02/2009 alle 17.54 +0100, Andrea Fazzi ha scritto:

> issue-timetracker.rb[1]:

[1] -
http://gitorious.org/projects/ditz/repos/remogatto-clone/blobs/master/lib/ditz/plugins/issue-timetracker.rb