Consider option to not use taskw about bugwarrior HOT 10 CLOSED

Yup. We should do that ;)

Instead of implementing this in bugwarrior, can we implement the changes in taskw so that everyone benefits? (There are other users of taskw out there).

Maybe we introduce it as an 'experimental' mode for taskw that we switch to the default some day.

from bugwarrior.

That seems like a good idea.

In using TW 2.2.0, it occurs to me that we might be able to use task merge to good effect. In theory, bugwarrior-pull could have its own TW task database at, for example, ~/.bugwarrior-tasks. bugwarrior-pull would add tasks to this database, and after adding tasks, could call task merge to merge the BW tracked tasks with the users local tasks. We could then call task push to push from the local tasks back to ~/.bugwarrior-tasks to keep everything in sync.

This may be simpler than a bunch of calls to task import and task export.

from bugwarrior.

That sounds like a clever approach. I suggested something similar for he
taskopen project, which I called "utility tasks". (see the examples folder
of the taskopen github)

from bugwarrior.

FYI I've started work on this here https://github.com/kostajh/bugwarrior/tree/task-merge.

from bugwarrior.

Awesome!

FYI, there is one test failing for taskw. I updated the test suite to run the same set of tests for both the normal implementation and the experiemental implementation. Try pulling the latest there on the develop branch, run python setup.py test, and you'll see.

The old "normal" implementation and the new experimental implementation return dates formatted in an inconsistent way. That might need a patch.

from bugwarrior.

Yeah, I've noticed that. How do you think this should be handled?

On Apr 8, 2013, at 12:16 PM, Ralph Bean [email protected] wrote:

Awesome!

FYI, there is one test failing for taskw. I updated the test suite to run the same set of tests for both the normal implementation and the experiemental implementation. Try pulling the latest there on the develop branch, run python setup.py test, and you'll see.

The old "normal" implementation and the new experimental implementation return dates formatted in an inconsistent way. That might need a patch.

—
Reply to this email directly or view it on GitHub.

from bugwarrior.

Another problem I've noticed: if using TaskWarriorExperimental, the key for an annotation on an upstream_issue will never match a local task, because with TaskWarriorExperimental the timestamp for an annotation will be the time that the annotation was added, while Bugwarrior expects to be able to add precise annotation names (see __init__.py line 105).

This means that BW will always report that it is updating a task, because the annotation keys never match.

I'm not quite sure of the best way to handle this.

from bugwarrior.

Yeah, I'm not sure. I tried messing with task annotate entry:some_date foo, but that modifies the entry date of the task (not the annotation like we need).

from bugwarrior.

Just got confirmation from @pbeckingham that taskwarrior 2.2 can't do this yet. It will hopefully be included in taskwarrior 2.3.

In the meantime, maybe taskw can just ignore the annotation date in our 'experimental' mode.

from bugwarrior.

Since we merged #67, I think we can close this issue. Please re-open if you disagree.

from bugwarrior.