gtg-contributors team mailing list archive

[Bryce Harrington <bryce@xxxxxxxxxxxxx>]

On Sat, May 22, 2010 at 02:03:28PM +0200, Luca Invernizzi wrote:
> >> > It was decided to have task only in one backend (if I remember, the
> >> > discussion was mainly with JML).
> >> > 1) consider that each task is in one backend and only one.
> >> We have also to consider that a fair set of r/w backends will not
> >> support a series of features that GTG taks have.  Take subtasks, for
> >> example.
> >> Say that I'm an unexperienced user, with my own tasks set, and I
> >> configure a Launchpad backend. I espect to be able to move the new
> >> imported tasks (Launchpad should be a read only backend) and place
> >> them under my task/project "become a great FLOSS guy" and maybe tag
> >> them @FLOSS.
> >
> > Tasks from RO backends should not be modifiable at all. No way to add a
> > tag, move it or change the parent. It's read-only. The interface should
> > reflect that.
> Ok, but maybe a guy with a lot of bugs like Bryce would like to organize
> them, tag them or make subtasks in order to lay out what to do to solve
> them.

Okay, first for the record, I definitely am planning that the launchpad
backend will be read/writable at least to some extent.  I haven't
thought it out in great detail but I've got a lot of experience
modifying launchpad bugs programmatically so I at least want to be able
be able to e.g. tag, close, milestone, comment on, unassign, etc.

But anyway, ignore that and let's think of launchpad as a read-only
backend.  Let me think about what I might do with such a backend here.

First, I can see a listing of my assigned bugs from gtg.  This can
already be done from my launchpad page, so really is merely giving me
alternate views of the same data.  Probably I'd just see the bug title
and description, not comments or other deeper info.  This all seems
quite simple and fits into the concept of read-only backend without any
issue.

But lets go a bit more sophisticated.


Second, I want to see my bug listing while offline such as if I'm taking
a long airplane trip.

a. With the read-only backend model, this works if it's able to store
cached copies of the data from one run to the next.

b. With the read-write backend model, it implies being able to resync
changes once I go back online.  Seems complicated but this would be
extraordinarily handy (it could be a killer feature for gtg amongst
launchpad users).

c. In the multiple-backend model, it is straightforward - the read-only
launchpad instance is updated whenever the network is present.
Meanwhile I can do whatever I like to the localfile copy of the task; I
just have to wait to manually update the launchpad bug when the network
comes back.

d. How else could this be done?  A multiple-backend with read-write
launchpad and a localfile, that allows me to queue up changes to the bug
report while I'm on the plane, and then have it auto-sync once I'm back
online.  That would be very sweet.  But probably I should put my
computer away and enjoy a good book instead.


Third, I want to keep notes on a bug I'm working on.  Specifically, as
I work on the bug I want to have a place to paste in error messages,
ideas about what's going on, or copy in other people's irc
conversations.  Stuff too random or personal or embarrassingly ignorant
to put into the bug report itself.

a. This wouldn't work with the read-only backend model as I understand
it, because once the bug task is re-sync'd I'd lose my notes.

b. This also wouldn't work with the read-write backend model, because
while I could persist the info back into the bug, I prefer to keep the
notes personal.

c. In the multiple-backend model, I would have two tasks, one in a
read-only launchpad instance, and a second in a localfile backend.  My
notes would be stored in the latter only.  So I'm good.

d. How else could this be done?  I imagine some sort of inter-task
linking thing, where I could create a localfile task which included a
reference or link to the launchpad backend task.  That's sort of a good
model for how I already do this (I put "lp #123456" in the title or
description of the task).  There wouldn't be any possibility for syncing
magic, but it would at least help keep me organized.


Fourth, using subtasks to organize my work.  I use the launchpad backend
to import my assigned bugs, and then I want to have a list of tasks to
do for each bug report, such as "Analyze; Code patch; Run tests on
patch; Propose merge; Get merge review; Land fix for bug".

a. As I understand it, this could not be done using the read-only
single-backend model.

b. With the read-write single-backend model, I could achieve this by
writing all the subtasks out in a text string and then appending it to
the bug description, like "Subtasks: 42@1 53@1 23@1".  But that's
extraordinarily kludgy (what happens if I reassign the bug to some other
gtg user?)  Also, it wouldn't enable me to keep personal notes on the
subtasks (everything would need copied back up to launchpad.)

c. With the multiple-backend model, the subtasks are kept in my
localfile store along with any notes or status changes.  They are
children of a task which exists both in my localfile backend and in the
read-only launchpad backend.

d. Other approaches?  The inter-task linking method mentioned in the
previous section could let me model this adequately.


Anyway, like I keep saying I don't think my understanding of how the
backends code works is very strong, so I expect some of what I've
written above is way off base, so please correct me where I've missed
something.

Bryce