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: 4...@1 5...@1 2...@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 _______________________________________________ Mailing list: https://launchpad.net/~gtg-contributors Post to : [email protected] Unsubscribe : https://launchpad.net/~gtg-contributors More help : https://help.launchpad.net/ListHelp
