| blob | 683087e06e8d2415a04db4b375b5803f0178b6bd |
1 \r
2 \r
3 \r
4 \r
5 # design feature list\r
6 =====================\r
7 \r
8 # task\r
9 ======\r
10 \r
11 # cooperation\r
12 =============\r
13 \r
14 # dev step trace\r
15 ================\r
16 \r
17 \r
18 \r
19 \r
20 \r
21 \r
22 \r
23 \r
24 \r
25 \r
26 \r
27 # introduce\r
28 ===========\r
29 \r
30 \r
31 \r
32 # method\r
33 ========\r
34 \r
35 files:\r
36 \r
37 @ todo: the maintainer of a src-pkg write the new feature list. if the feature \r
38 would be append in plan, put it in active-queue in the doc, under a version\r
39 id to be published. one version of tech-task will be append to 'todolist',\r
40 when the todolist is empty. it will append task beyound tech-task, such as\r
41 design-procedure, testing-procedure, document-procedure, publish-procedure,\r
42 to architect a full flow of new feature dev.\r
43 @ todolist: tasks to be done for a version. it comes from task set for one \r
44 version in 'todo' file. developer use 'devtask list' to see the work they \r
45 can do, and use 'devtask get <task-id>' to put it into 'worktasks.tmp'.\r
46 @ worktasks.tmp: task to be done for a developer in one copy of src-pkg dir. \r
47 task-id comes from todolist. it's the todolist for developer.\r
48 @ features: full feature list for the software.\r
49 @ changelogs: news history log.\r
50 @ news: changes between last version.\r
51 \r
52 \r
53 note.tdr: note for new ideas, improvement, bug-report, suggest issue, and any \r
54 thing others about the src-pkg.\r
55 todo: the feature plan to do in different future version. develop task will get\r
56 features in one version, put it into todolist until done, and get the feature\r
57 in next version, until all of them are done.\r
58 this file is a .catalog file, all features orgnized with category. there\r
59 are two queue in the file, one is active-queue, the other is inactive-queue.\r
60 the queue of inactive-queue is saved with features which is not needed to be\r
61 implemented now. the features in active-queue would be implemented in plan.\r
62 code for appending new features in 'todo' file is forked in new branch. \r
63 when a version of features is done, modification in main version since it was\r
64 forked will be combined into new branch. combine new branch code into main \r
65 version when loop-back testing is ok.\r
66 bugs: it record the bug reported and re-tested. it also have two queues to be\r
67 done like todo file. code for bug-fixing is the main version code.\r
68 todolist: the features & bug-fix in the queue of plan. one feature enable one \r
69 develop task for new feature. when all tasks in it are implemented, testing\r
70 and document, then publish as a new version.\r
71 feature-list: the feature has been implemented.\r
72 changelog: feature and bug-fix list in different version.\r
73 new: the feature & bug-fix different from last ver.\r
74 \r
75 \r
76 \r
77 # utility program\r
78 =================\r
79 \r
80 @ devtask append\r
81 it open the text content in tagdoc, and translate note text into a feature\r
82 message with short-name, version id, activity state.\r
83 \r
84 @ devtask list <task-type>\r
85 task-type can be 'analysis', 'design', 'dev', 'doc', 'tran', 'test', \r
86 \r
87 @ devtask get <task-id>\r
88 task id is a random hex-number, or a short name without blanks.\r
89 when this cmd invoked, it put the corresponding task-id into the file \r
90 'worktasks.tmp'.\r
91 \r
92 task conflection. one developer implement a task, and the other is do this\r
93 work too, when the code is commited, the local file of todolist is conflected \r
94 with the one on the server. \r
95 before 'devtask get <task-id>', it check email info, and there are no one\r
96 hold the task, and send an email to developer list to nodify others to hold \r
97 this task, then do the next operation. it's a simple method to solve task \r
98 conflection, but not very well.\r
99 before 'devtask submit <task-id>', it pull file of 'todolist', check if \r
100 the task is completed by any others. then send the email of task done, at last,\r
101 it commit files to code repo.\r
102 normally, before get the task, others will check email info, and could not \r
103 get the task. if others receive the email and seen, also would not to get the\r
104 task in 'todolist'. although, email is not a real time response method, but \r
105 humen operation is also not a real time operation in short times.\r
106 \r
107 another method is public lock file in code repo. try to pull lock file \r
108 instead of resolve email info. but also send email to others for text info\r
109 nodification.\r
110 \r
111 @ devtask submit <task-id>\r
112 it get the task-id in worktasks.tmp, and delete it in the file. it get the \r
113 task in todolist, copy the content to 'news' and 'changelogs' if it is a \r
114 feature or a bug-fix task. then, delete it in 'todolist'.\r
115 \r
116 @ devtask launch [task-id-ver]\r
117 if there is no paramter after 'launch', it list the task in 'todo'. launch\r
118 the task by name of task id and task version. it put tasks into 'todolist'.\r
119 \r
120 @ devtask launchback [task-id-ver]\r
121 put the task info in 'todolist' back to file of 'todo'. normally, the work\r
122 in 'todolist' have not been taken by others.\r
123 \r
124 @ devtask suspend [task-id-ver]\r
125 suspend task, put save 'todolist' as 'todolist-<date>.suspend'.\r
126 if no name specified, the default operation is the current 'task-id-ver'.\r
127 \r
128 @ devtask resume <task-id-ver>\r
129 resume task if current 'dotolist' is empty. or type 'devtask suspend' \r
130 first.\r
131 \r
132 @ devtask \r
133 when the feature is not plan to be developed, but it has been append to \r
134 'todolist'.\r
135 \r
136 ##########\r
137 files '.tagdoc' 'todo' 'todolist' 'worktasks.tmp' is used to implement a \r
138 type of work-task-distribution from demond text doc to feature list analysis, \r
139 to actual work tasks.\r
140 those work above can be done without the util program of devtask. but the\r
141 developers will have the same conception of task distribute and cooperation.\r
142 \r
143 \r