gtg-contributors team mailing list archive

[Lionel Dricot <ploum@xxxxxxxxx>]

Dear students,

This is great to see the enthousiasm. Luca, btw, congrats for your
flashplayer. I will be surprized if you don't make /. first page ;-)

I point to insist on one aspect of GNOME SoC : the weekly report. I want
you to send, every weekend, a weekly report.

You must send it to the gnome SoC mailing-list, gtg-contributors and post
it on your blog (or a blog specially dedicated to that. If you want a blog,
just ask me for one on fritalk.com). The blog can be a modified version but
please post on your blog at least once per week. If it bores you, just
copy/paste the weekly report, we don't mind.

Here's my suggestion for a weekly report template. Feel free to not follow
it as long as you think that we, mentors and outsiders, have the important
information.

The title of the mail should contains : "My Name GTG SoC week X (Y weeks
left)" (or anything like that, you see the point.)

Your report should contains the following informations :

1) One short sentence describing your week and how you feel for the
project (Ex : "A very productive week writing code but no documentation at
all")
2) What you achieved this week
3) What was expected and was not achieved
4) What you will achieve next week (and why it is useful to achieve the
final goal)
5) What are your main problem to achieve the complete objective
6) Anything you want to share 


Now, let being practical.

Paul > I like your wiki page but I still fail to see one clear objective.
I like the idea of having some kind on "tasks generalisation". I immediatly
do the connection with a DBus representation of a task. Maybe, you should
talk a bit about that with Bryce.

Possible objective : having a "tasks" server, thus including doing the
separation between gtg-core and the UI. This include making a clear and
complete DBUS API (that's why I think Bryce advices would be useful). This
tasks "server" would come with a shitload of tests. To make jml happy, I
would encourage you to make the tests before the actual code ;-)
I would also like you to specially consider our cooperation with Hamster
and Tomboy, maybe by talking with people in there respective communities.

How do you feel about that ? Could you rewrite a real goal with that in
mind and then rewrite your schedule a bit ?

Also, please add your blog to planet.gnome. If you want a blog only for
the SoC, contact me.

TODO this week: 
- put your blog on pgo
- rewrite your final goal in one sentence
- rewrite your planning according to that goal
- post on pgo a report 0 (or 1) describing your project to everybody.


Luca > Now, you are an opensource rockstar and on planet.gnome ;-) I think
that, on your side, the goal is crystal clear. But I want to formalize
things a bit. I want you to proactively ask me for a code review every week
as you are already coding a lot. Only code : no UI decision there. I also
want you to start to write some tests for the backends. Yes, I will make
your life harder this summer ;-) Maybe, it could be a good idea to
periodically merge some of your patches to trunk, we will see.

As you have a clear advantage over other students here, I also want you to
fix some of the regressions from 0.2 to trunk. You can choose which one are
the most important to fix so your work is useful. 

TODO this week:
- tag as "regression" the bugs which are regression
- report regression still not reported yet
- assign at least two regression to yourself. (hihi, I like being a
mentor)
- write at least one test for the backends (it doesn't have to pass yet)


Karlo > Please read my comment for Paul. As I understand, you will not
code directly into GTG. Instead, you will code another UI, using Django.
Consider that the "GTG server" of Paul will be operationnal. I suggest that
your Django application uses DBus to communicate with the GTG server. You
will expose the DBus API through a web API so Luca can connect to it and
you will also do a web interface for those who don't have GTG installed. Am
I right ?

I would like you to start by doing a fake task server. A simple python
script that return fixed constant, completely fake then, but already over
DBus. This way, you will be able to develop your Django app transparantely
and connect seamlesly with Paul's work. Take the current gtg-dbus file as a
model and make it return constant.
Also, create you Django project :-)

TODO this week: 
- put your blog on pgo
- post on pgo a report 0 (or 1) describing your project to everybody.
- set up a django project and create a bzr branche (or git or whatever) to
host it.  Bertrand can help you for this.
- Write a fake gtg-server that serve tasks over DBus.


Waw, that's a lot. Of course, you can discuss as this only represent my
own vision. Feel free to do things differently if you want ;-)


Cheers,

Lionel