Hi, Robert David wrote: > I'm sending copy of my proposal to ml. Thanks, and sorry for a slow response. Full disclosure: I locally use a patch[1] to teach a --patience option to add -p, checkout -p, etc (to use the "patience diff" algorithm). I never submitted it since it wasn't clear to me how to integrate it (and other diff options) properly. I will be very happy to see a cleaner add--interactive. So I'm a likely early consumer of your code, although I don't think I'll have time to co-mentor. Luckily there seems to be no shortage of willing mentors. Some quick impressions. This is off-the-cuff; please feel free to let me know if something sounds crazy. > Today git code consists of the base written in C and many helper shell or PERL > scripts. While at a first time it is easier to write the script, final code is > supposed to be in C. One of these scripts is git-add--interactive. [...] > But before that, it is need to clean and extend the current git-add-- > interactive, to serve user needs at the best. I see two goals in tension: (1) to integrate add--interactive as C code, and (2) to clean it up and change its feature set. Either one could happen without the other, and for planning it would be useful to know which is going to drive decisions (e.g., what if time is short and something has to get cut?). If (1) is the main goal, it might be easiest to first translate the existing code, perhaps modulo small preparatory changes that make the translation easier, into C and leave major changes for afterwards. Tracking down bugs due to a major change (like switch in implementation language) is a lot easier if the pre-change version is well tested and well understood. If (2) is the main goal, it might be easiest to rewrite small parts of add--interactive in C where convenient rather than rewriting the whole thing. In that story, the result is a series of small patches without any single world-changing patch. :) [...] > How to consider this project has success? That is pretty easy, the already > done functionality will be integrated in git-add and the user usage would be > consistent. After each patch, the test suite should pass. If some important functionality is not exercised in the test suite, ideally it can be added to the test suite. (Though that's no replacement for trying the changes in day-to-day use, of course.) [...] > The official time-line consists of 12 coding week, starting 24th May. The mid- > evaluation is in the 8th week. > So the plan is written in week order beginning on the first coding week. Jeff and Junio's advice seems sane to me. More advice that might help with writing a timeline: [2] and Christian's reply. Because of the uncertainty I mentioned above, it's hard to give an example, but an ideal proposal would include a timeline that gives a technical plan for the summer. Also during the bonding time or even earlier it would be nice to get used to sending patches and reviewing them (as explained in Documentation/SubmittingPatches) if you find time for it. Thanks again, and hope that helps. Jonathan [1] http://bugs.debian.org/522361 [2] http://thread.gmane.org/gmane.comp.version-control.git/142623/focus=142877 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html