Attendees: abdellaoui, bassdeal, j_k9, shilpa

Note: All timestamps in UTC+2.

This meeting's agenda can be found here.

As sent to the Mira Development Mailing List on 21/09/2011 with the subject: “Summary of 18/09/2011 Meeting”:

Hi all,

Sunday's meeting was attended by John, Shilpa, Zied and myself. A transcript of the meeting can be found here:
http://miragroupware.org/wiki/doku.php/development/communication/archives/110918_meeting

This meeting had a brief agenda, which can be found here:
http://miragroupware.org/wiki/doku.php/development/communication/agendas/110918_meeting

We spoke first about meeting times. Following the mailing list thread on the same topic, we have decided to hold the next meeting (on Sunday 2nd October) at 13:00 UTC. This is the time that proves most convenient for all of us. At least, John, Shilpa, Zied and I all said that the time was suitable on a Sunday. If you find that this time is inconvenient for you in the long-run, please reply to the other thread regarding meeting times with your own preferences and we will do our best to accommodate everyone in the future.

John has made excellent progress with his MySQL and SQLite database interfaces for the Directory layer. He has stabliised the MySQL interface, and has moved code which is common to both interfaces up to DbDirectory (above DbSqliteDirectory and DbMySqlDirectory). He has also removed a lot of commented out, archaic code. Finally, as you will have seen on the mailing list, he has prepared detailed instructions on how to configure the Server to use a database backend to store Directory data.

The blueprint for the database backend to the Directory layer that is found on the wiki is now out of date, because I prepared it many years ago. John intends to update it to correct the record structures detailed therein.

John also mentioned that he would like to merge his branch into our main branch, trunk. Given that his code is feature-complete, it just needs to be tested before it is merged into trunk. I am going to do some testing this weekend. If anyone else can join in with the testing, please do - the more usage, the more likely it is that we might spot a bug at this stage. We will follow the procedure detailed here to merge John's branch: http://miragroupware.org/wiki/doku.php/development/workflow and here: https://help.launchpad.net/Code/Review

Shilpa has made very good progress on the Network layer. She has had to change almost all of the network protocol in order to implement Google Protocol Buffers. This will allow binary data transfer between Client and Server, because the messages are no longer parsed according to a special splitting character sequence. Instead, Shilpa's protocol first sends the length of the message, and then the message. Shilpa has already converted the Login, New User, and Join Group messages. Now that most of the groundwork is done, she will continue to convert the other messages over the next few weeks.
Shilpa has been developing this on a local Bazaar branch. She would prefer to get the code stable before pushing it to Launchpad, but I suggested that she should push it to Launchpad and keep pushing new commits regularly in order to evade the conflicts that arose the last time that a major change was pushed in one go. Shilpa agreed to try to push her code to Launchpad the next time that she works on it.

Zied has moved to a new job, and is now eager to contribute to Mira. (Welcome to the team, Zied!) He said he was interested in splitting Shilpa's task and working on converting some of the network messages to use GPB. Shilpa said that this might be difficult because some messages rely on other messages (such as the Login message, which also required changes to the List Workplace and Status messages), so it would be difficult to draw a line down the middle and split the messages between them. However, Shilpa said that she would look at the code and see if it would be possible to split the task between them. She will then email her conclusion to the mailing list. If it turns out that splitting the task would be too difficult, there are plenty of tasks remaining for Mira v0.2 to choose from: http://miragroupware.org/wiki/doku.php/development/roadmap/outstanding

John would also like to change a few of the messages to make the database interfaces work more efficiently. For example, one change would involve splitting the message to update a Workplace into separate add subscription and delete subscription messages. He intends to make these changes once his branch has been merged into trunk.

Finally, John mentioned that the links on the wiki to download the Qt libraries were broken. I have now fixed these.

Best regards,

Max Bossino
Project Manager
http://miragroupware.org

[22:17] j_k9: How are you, Shilpa?

[22:17] j_k9: It has been a long time since you were last able to attend a meeting at this time.

[22:17] shilpa: Doing good. How about you.

[22:18] shilpa: Yes. Sundays this time is hard to commit.

[22:18] j_k9: I'm well, thank you. Is it late afternoon for you?

[22:19] shilpa: Yes. It is around 3pm here

[22:19] j_k9: Right. Well, to be honest, this time is not fantastic for me either - it's past midnight, and I have work early in the morning. But it seems that at least three of us would be happy with 13:00 UTC?

[22:20] shilpa: Yes 13.00 UTC would work really good for me.

[22:20] bassdeal: Bummer Max.

[22:21] bassdeal: Lets see 13:00 UTC is 8:00 EST. I can do that but Shilpa isn't that 5:00 PST for you?

[22:21] j_k9: That's alright. We don't have a huge amount to talk about (mainly your work, John), so I'm expecting to be asleep by 1am :)

[22:22] shilpa: So is Jhon going first?

[22:22] j_k9: John, do you really not mind 8am on a Sunday? It's not much of a lie-in!

[22:22] shilpa: I can also provide my update later

[22:23] j_k9: Yes, Shilpa, that would be great. But regarding future meeting times - what time is 13:00 UTC for you?

[22:24] shilpa: With Daylight saving time it will be 5am and after that 6am.

[22:24] bassdeal: Sorry right. I had it reversed

[22:25] j_k9: Are you sure that is convenient for you, Shilpa?

[22:25] bassdeal: Wait. I think I was right the first time. EST is UTC -5, EDT is UTC -4.

[22:25] shilpa: It wirks good for me.

[22:25] shilpa: I mean works

[22:25] bassdeal: Works for me also. I am a morning person.

[22:26] j_k9: Great :) I'm not a fan of lie-ins either. Zied, would you be able to attend at 13:00 UTC?

[22:27] abdellaoui: yes , great

[22:27] j_k9: Fantastic. Alright, let's arrange the next meeting for 13:00 UTC.

[22:27] shilpa: Sounds good.

[22:27] j_k9: John, would you like to begin by discussing what you have accomplished with your branch over the last few weeks?

[22:30] bassdeal: OK. I have stabilized the MySQL side of the DbDirectory. I have also moved some common code from the DbSqliteDirectory and DbMySqlDirectory and placed it in the DbDirectory. I also removed a lot of commented out code. Lastly, I sent around a document on how to configure the server to use SQLite or MySQL.

[22:31] j_k9: So, just to confirm, your MySQL and SQLite interfaces are now feature complete? They just need to be bug tested, and then merged into trunk?

[22:33] bassdeal: As far as I can tell both SQLite and MySQL work with all commands from the trunk version of the client. Note much of the detail documentation of the DB backend on the Wiki is not accurate anymore.

[22:34] j_k9: Excellent. Yes, the wiki documentation will have to be revised - are you referring to the Database backend blueprint?

[22:34] bassdeal: Yes. the record structures are not accurate.

[22:36] j_k9: Shall I delete that page altogether? Or would you be interested in reworking it? It might be useful as a reference, but no more than that, given that you have finished implementing it!

[22:37] bassdeal: I would like to update the documentation.

[22:38] j_k9: Ok, great. Excellent work on this task, John - I'm really looking forward to testing it out. I will let you know how that works out!

[22:38] bassdeal: I sure you will .

[22:38] j_k9: Shilpa, would you like to go next? :)

[22:38] shilpa: Sure.

[22:39] bassdeal: Before we are done, I would like to ask about merging into the main branch.

[22:39] bassdeal: But Shilpa can go ahead.

[22:40] shilpa: So changing the n/w message from string to GPB message needed lot of ground work.

[22:40] shilpa: I had to change mostly all the network protocol.

[22:40] shilpa: for GPB to work.

[22:41] j_k9: Shilpa, have you been using a Bazaar branch for this work?

[22:41] shilpa: Earlier messages between client and server were parsed based on some special char. like space.

[22:42] shilpa: Yes. I have local protocol-buffer branch.

[22:42] shilpa: Getting back, now I first send the length of the message and then the message

[22:43] shilpa: that way we don't have to parse the messge using special characters.

[22:44] shilpa: This was done to include the binary data transfer between client ans server.

[22:44] shilpa: The ground work for the GPB is almost done.

[22:45] shilpa: I have coded Login, New User, Join group messages

[22:45] shilpa: It looks to work weell.

[22:46] shilpa: In following weeks I will finish the rest of the messages.

[22:46] shilpa: Any questions?

[22:47] j_k9: Well done, Shilpa. My only question is: would you be able to push your branch to Launchpad for the rest of us to see? I, for one, would be very interested to see how you change each message.

[22:47] bassdeal: Sounds very cool. The ability to binary transfer is very important.

[22:47] j_k9: Also, I want to make sure we avoid the problem we encountered last time, where so many changes had been made that the branch could not be merged into trunk.

[22:47] shilpa: I will try to get the code stable before I push it.

[22:48] shilpa: Yes. I will try to do that next week.

[22:48] j_k9: It wouldn't be a bad thing to have your code on Launchpad even if it is not stable/ready. That way there's some redundancy, at least. And we also avoid the Bazaar going crazy error :)

[22:49] j_k9: But it is up to you. If you would prefer to push it once it's ready, that's absolutely fine.

[22:49] shilpa: ok. makes sense I will try to push the code next time I get to work on it.

[22:50] shilpa: Jhon Thanks.

[22:50] j_k9: That would be great, thank you.

[22:51] j_k9: Zied, you said earlier that you were interested in taking a more active role in Mira's development. Is that right? :)

[22:52] abdellaoui: yes

[22:52] j_k9: Do you have a particular task in mind that you would like to work on?

[22:52] abdellaoui: can I help Shilpa in merging her code to GPB

[22:53] abdellaoui: I meant adapting the rest of the messages to GPB format

[22:53] j_k9: Oh, I see. Shilpa, how would you feel about splitting the workload?

[22:53] j_k9: Perhaps you could take a share of the messages each? Or would you prefer to work on it yourself?

[22:53] j_k9: There are plenty of tasks to go round :)

[22:54] abdellaoui: Otherwise , I'm open to any proposition

[22:54] shilpa: I don't mind splitting it but I don't know at this point how to do it.

[22:55] j_k9: Shilpa - If you push your branch to Launchpad, then Zied could simply pull the branch, change one of the messages, then push the update.

[22:55] j_k9: As long as you decide who would work on which messages beforehand, there shouldn't be any conflicts.

[22:55] shilpa: ok.

[22:55] j_k9: Are you happy with that arrangement?

[22:55] abdellaoui: YES

[22:56] shilpa: only problem is lot of messages are liked to each other, for eg.

[22:57] shilpa: for login message one has change list workspace, status login/logoff

[22:58] shilpa: for list workspace some other message need to be changed

[22:59] shilpa: So I am really not clear on how to do the split.

[22:59] j_k9: Hmm, I see. That might create conflicts, if you both start changing the same message…

[22:59] shilpa: yeap.

[23:00] shilpa: How about let me look in the code with the idea of spliting the work.

[23:01] shilpa: If I can find an easy spilt I will let you know via mail

[23:01] j_k9: Ok, that sounds like a good plan. Shilpa, would you like to email the list with your conclusion? If it can be split, great. If not, then perhaps we could find Zied another task.

[23:02] shilpa: Yes. I can do that.

[23:03] abdellaoui: that's great so

[23:03] j_k9: Excellent.

[23:03] j_k9: Does anyone have any questions or comments?

[23:04] bassdeal: I have a question/comment.

[23:04] j_k9: Yes, regarding merging your branch?

[23:05] bassdeal: Yes. I still have some work I can do but soon it will be done. The DB stuff is quite isolated so should have minimal impact on others. I think it will soon be a good time to merge it in the main branch.

[23:06] j_k9: Ok, that's not a problem. We can just follow this procedure: http://miragroupware.org/wiki/doku.php/development/workflow

[23:06] bassdeal: Also, as I mentioned a few weeks ago, I would like to add/change some of the messages to make the DB operate more efficiently. However this can wait until after the GPB work is done.

[23:06] j_k9: That links to Launchpad's (and Bazaar's) instructions on merging branches, and ensures that all the appropriate records of the merger are kept. The link is: https://help.launchpad.net/Code/Review

[23:07] j_k9: Sure, sounds good.

[23:07] shilpa: What messages would you like to change?

[23:08] bassdeal: Max. OK. I want to try one more thing on the MySQL side then if things still look good I will propose a merge.

[23:08] shilpa: Just wondering could be done together.

[23:10] j_k9: Yes, John, I think that's a good idea. It is silly to keep your branch separate from trunk once we have confirmed that it is stable.

[23:11] bassdeal: Shilpa. The update workplace (can't remember the code now). It seems this is currently only used to add a subscription to the workplace. However, the DB side has to take to account that just about anything could change. So it reads all the current subscriptions of the workplace, then compares these to the ones in the workplace message then adds/deletes any differences. It would be much better to have separate add/delete subscri

[23:11] bassdeal: I hope that makes sense.

[23:11] bassdeal: Also I suspect most changes to workplaces will be subscriptions, not things like description or name.

[23:12] shilpa: Sounds good idea.

[23:12] shilpa: But not sure about discription.

[23:13] bassdeal: But the Directory works as the message stands. Just not very efficient and the code is more complex than it has to be to accommodate the update workplace message.

[23:13] bassdeal: I doubt the description of the workplace will change much once it is created.

[23:14] shilpa: right.

[23:14] bassdeal: If it does that is fine but no need to resolve the subscriptions because the description changed and vis-versa.

[23:14] shilpa: I think we should do this now rather than waiting for GPB to be done completely

[23:15] shilpa: If you can provide excat details of how you want the message

[23:16] shilpa: then when the message is updated we can consider what you want from the message.

[23:16] bassdeal: Well I would like to get the DbDirectory in the trunk then add/change messages. Changing the messages would involve other parts of the server and the client. Right now the DB stuff basically isolated to a small part of the server (almost all additive).

[23:17] shilpa: ok.

[23:18] j_k9: Is that alright, then?

[23:18] bassdeal: I think it will be less work this way overall.

[23:19] bassdeal: OK with me.

[23:20] shilpa: ok with me too.

[23:20] j_k9: Great. Does anyone else have a question or comment?

[23:20] shilpa: No.

[23:21] bassdeal: Just a comment. The link on the Wiki to download the QT software does not work anymore. I am looking at the site now since I am moving my environment to my “winter” computer. Trying to figure out where the download is.

[23:22] bassdeal: Once I find it I will let everyone know.

[23:22] j_k9: It was bought by Nokia: http://qt.nokia.com/downloads/downloads#qt-lib

[23:22] j_k9: I will update the links in the wiki page tomorrow. Thank you for letting me know :)

[23:23] bassdeal: Great! The QT website is in Dutch. Having a bit of difficulty figuring out what is what.

[23:23] j_k9: Haha! Yes, that might confuse :)

[23:23] shilpa: Sorry to interrupt but I will have to go.

[23:23] j_k9: I think we can wrap this up. Thanks to all of you for joining! I will send round a summary to the mailing list tomorrow. We will arrange the next meeting for 13:00 UTC, two weeks from now.