[19:02] <Caroline> hello?
[19:03] <dfarning> hey Caroline
[19:03] <Caroline> hey
[19:03] <Caroline> I made it
[19:03] <Caroline> in a coffee shop
[19:03] <dfarning> just talked to manu he will be leading the meeting and doing introductions
[19:04] <dfarning> how is the coffee?
[19:04] <Caroline> I was rushing to gt logged in and haven't gotten any yet!
[19:05] <Caroline> if its going to be a few I'll go get some. :)
[19:05] <dfarning> ok am watching the wireless generation videos on my nieces laptop.
[19:06] <dfarning> I will read the papers this evening.
[19:06] <Caroline> cool biab
[19:07] <dfarning> band in a box?
[19:07] <dfarning> ahh back in a bit:)
[19:15] <Caroline> ok I'm back
[19:15] <Caroline> ok I'm back
[19:15] <Caroline> no Manu or Ian?
[19:16] <dfarning> net yet
[19:17] <dfarning> Caroline, not sure what happened to Ian. manu may be having time zone problems
[19:18] <dfarning> in the mean time http://lwn.net/SubscriberLink/387196/012bee6d6d0b95d0/
[19:19] <dfarning> meego is defaulting to btrfs
[19:19] <dfarning> just pinged manu
[19:21] <manusheel> dfarning: Hi David.
[19:21] <dfarning> manusheel, gooe afternoon
[19:22] <dfarning> manusheel, what city do you live in?  I would like to add it to my gnome clock.
[19:22] <manusheel> dfarning: New Delhi, India.
[19:22] <manusheel> State = Delhi.
[19:24] <dfarning> ok got it thanks.  Is it 1150 pm for you?
[19:24] <manusheel> dfarning: Yes, 11:54 pm.
[19:24] <dfarning> great Caroline are you back?
[19:24] <Caroline> yes
[19:25] <manusheel> Caroline: Hi Caroline.
[19:25] <dfarning> manusheel, would you like to start?
[19:25] <manusheel> dfarning: Sure, thank you.
[19:26] <manusheel> Wish to share our plans for the next 3 months.
[19:27] <dfarning> great I think yesterday was about making sure we were in agreement on the high level goals. today is tatical plans and implementation
[19:29] <dfarning> manusheel, did we lose you?
[19:30] <manusheel> dfarning: I am here. Sorry, some network issues at my end.
[19:31] <dfarning> manusheel, np.  looks like we have several communication related issues to work out.
[19:32] <manusheel> dfarning: Yes, I did work out the implementation level details that could match our needs.
[19:32] <dfarning> manusheel, great
[19:32] <manusheel> dfarning: My apologies again.
[19:33] <manusheel> dfarning: We arrived at a set of 4 specific areas that could help us arrive at a point, where we can make USR available for deployments -
[19:33] <manusheel> 1. Getting the mouse control areas worked out. There are a number of issues on this front at this juncture;
[19:34] <dfarning> ok
[19:35] <manusheel> 2. Have the basic Sugar user interface working with the basic set of functionalities. The resolution and even the display of Sugar home in USR is not in sync with other Sugar distributions;
[19:36] <dfarning> yes
[19:36] <manusheel> 3. Have the control panel and basic set of libraries working. Example - Abiword library, which supports Write and Newspaper. This will require us to get into the API level details, and matches with our work on API documentation.
[19:37] <manusheel> 4. Get the activities working by closely working with activity authors. This part would start when we initiate the earlier step. As we agree, trust and cooperation cannot be surged.
[19:37] <dfarning> yes.
[19:38] <dfarning> with reguard to brower libs have you looked at surf in stead of browse?
[19:39] <dfarning> http://surf.suckless.org/
[19:40] <manusheel> Yes, we did look at it. It is a very good program. However, we are yet to understand the leadership maintaining this activity.
[19:41] <manusheel> We would like to work with them, if they that sense of scalability and sustainability in their goals and operational dynamics. Learning lessons from the loss of PyXPCOM.
[19:41] <manusheel> have that*
[19:42] <dfarning> agreed.
[19:43] <dfarning> is abiword well supported?
[19:44] <manusheel> Yes, abiword is well supported. Not pyabiword. Thats the problem, and we are trying to fix this with Martin.
[19:44] <dfarning> or pyabiwork in our case?
[19:44] <manusheel> Abiword is on a major expansion. They have moved to platforms like Maemo too.
[19:44] <dfarning> was pyabiwork a olpc project?  I don't know its history.
[19:45] <manusheel> Pyabiword was supported by OLPC volunteers. Martin Seviour was the lead.
[19:46] <dfarning> so if we want to depend on it we will need to ensure its continued development.
[19:47] <manusheel> Yes, absolutely. We need a maintainer for Pyabiword. We have trained two developers at SEETA to work with PyAbiword too.
[19:48] <Caroline> how crazy would it be to sugarize Open Office for kids instead?
[19:48] <dfarning> great. pyabiword can be a area where we can significantly help support upstream.
[19:49] <manusheel> Caroline: It is a very interesting project. We are developing interoperability between SocialCalc and open source spreadsheet from Open Office.
[19:51] <manusheel> Sugarizing Open office is going to take time. But, a very interesting project.
[19:52] <dfarning> are there other libs besides pyabiword that will need significant support?
[19:52] <manusheel> It is not a crazy idea. However, C language has been used a lot in open office. So, we'll have to spend time on C-Python bindings.
[19:52] <manusheel> dfarning: Yes, we can support pyabiword upstream.
[19:52] <manusheel> There are other libraries as well.
[19:53] <manusheel> But, Pyabiword fits our use case very neatly. Some of the other libraries use QT.
[19:54] <manusheel> I'll be sending a memo to Tomeu on his progress on PyQT. Someone from Finland, did port Sugar on QT based Nokia tablet, as far as I remember.
[19:54] <dfarning> I don't think the port to the nokia tablet ever got start:(
[19:55] <dfarning> You mentioned issues with the control panel?
[19:56] <manusheel> dfarning: Ok, it appeared on the author's blog that he did manage to do it. I'll check and send you the link to the blog.
[19:56] <manusheel> dfarning: Yes,
[19:56] <Caroline> i have to run
[19:56] <dfarning> ok great.  I did not hear that that got completed.
[19:57] <dfarning> talk to you later caroline
[19:57] <dfarning> what are the issues with the control panel?
[19:57] <manusheel> we have a good number of issues on the control panel front. Language switching is a problem right now.
[19:58] <manusheel> When we switch to say Colombian, and want to switch back to English US, the language settings does not work as expected.
[19:58] <manusheel> Spanish (Colombian)
[19:59] <dfarning> it this a bug or differences in design between olpc and ubuntu?
[20:00] <manusheel> stays there. And, it overrides the event to switch to English. I think it is an issue due to difference in design. We are yet to get into the ground level details of this issue.
[20:01] <manusheel> We are focusing on our point number #1 - mouse control. David, I'll be adding one QA expert per area this week, who can investigate and document the issues as developers work on fixing them.
[20:02] <dfarning> ok that is a good approach.
[20:02] <manusheel> dfarning: This is how I see the software engineering life cycle moving at our end -
[20:02] <dfarning> how are the basic patching and packaging tasks coming?
[20:03] <dfarning> are developers getting up to speed?
[20:03] <manusheel> dfarning: You'll see packages been uploaded by new developers before the weekend starts. Yes, the progress seems to be coming along pretty well. Getting good feedback on their learning curve.
[20:04] <manusheel> We have asked them to work on 0.88 tarballs at this juncture in reference to packaging.
[20:04] <dfarning> great.
[20:05] <manusheel> dfarning: So, the engineering life cycle is as follows -
[20:06] <manusheel> 1. We have identified the areas (discussed above). We'll be preparing business required specification documents per area to help meet the important needs of the user. Basically, a set of areas, which we need to be good at before we reach the shipping point.
[20:07] <manusheel> 2. Ask the developers to get a good hang on the code parallely and ask the QA guys to create test plans for each area. Automated test plans might be an easier approach here.
[20:08] <manusheel> 3. Ask the QA team members to raise tickets in the bug track with issue, steps to reproduce the issue and resolution to the issue.
[20:09] <manusheel> 4. These issues will be first examined by the project managers specific to areas before they release them to development.
[20:10] <manusheel> 5. Once the issues get released, the development manager will assign them to the developers according their areas of code familiarity and expertise. This is one phase where handholding would be required from our side. The discussions should be kept in sync with the timelines.
[20:11] <manusheel> 6. The developers fix the issues, and assign back to the QA team. The QA team verify the issues, and add release notes (one per issue).
[20:12] <dfarning> Ok, so as issues move to step 5, we will need to look for subject matter experts to help with leaning?'
[20:12] <manusheel> 7. In parallel, we'll have the user guide and architectural level documentation being initiated by two team members working on documentation efforts at this juncture.
[20:14] <manusheel> dfarning: We'll have to identify them as we begin creating the release cycle goals. They can help us audit our BRDs (Business Requirement Documents) with focus on functional deliverables.
[20:15] <dfarning> good, that will give us more lead time.
[20:16] <manusheel> dfarning: I think a good point to start working with them will be when we have done the initial document per functionality ready at our end. They will help us establish if we need to re-work on the document, or we are good to go in terms of meeting the shipping needs of our clients (OEMs).
[20:17] <manusheel> dfarning: I almost ready with the template
[20:17] <manusheel> for doing functional level documentation and BRDs.
[20:17] <manusheel> Will send it across by Saturday.
[20:17] <dfarning> great.
[20:18] <manusheel> It has the desired format and we should be able to capture the details succintly.
[20:18] <dfarning> what are we looking at for cash burn rate over the next 6-12 month to support this implementation?
[20:21] <manusheel> dfarning: Right David. I'll send you a plan on the first 6 month period. Yes, it is indeed a 12 month long project. I think we should have Q1 release in 11 months. The last 1 month will be on assessment and documentation.
[20:21] <manusheel> Code freeze and feature freeze timelines can be worked out once we have the BRDS with us.
[20:22] <dfarning> ok, I'll look forward to getting those.
[20:23] <dfarning> What are the most important things you need from me over the next couple of weeks/months?
[20:23] <manusheel> dfarning:  Have one person per subject area working with me on defining the functionality document and set of features we would like to support in the first release.
[20:24] <manusheel> Someone, who would have worked on these respective areas before.
[20:24] <manusheel> That would expedite our processes.
[20:24] <manusheel> dfarning: We would like to have the BRDs worked out by June end.
[20:25] <manusheel> This should capture fine details of our work.
[20:26] <dfarning> ok, as you identify these area, I'll work on engaging particular people.  There are a lot of former OLPC developers with a great deal of knowledge but limited time/interest to commit
[20:27] <manusheel> dfarning: Ok, if time is the constraint, they can provide us the bigger picture view. And, we can take up from there.
[20:28] <manusheel> They can be our consultants.
[20:28] <manusheel> dfarning: Do we have someone, who can commit certain number of hours per week on helping us define the BRDS?
[20:29] <dfarning> Ahh I think they we be willing to help with brds... they just don't have time/interest to hack.
[20:30] <dfarning> Let me think about that.  what expertise are you looking for?
[20:30] <manusheel> dfarning: Expertise to help arrive at a list of features per functionality, and define deliverables around it.
[20:31] <manusheel> A set of critical features
[20:31] <manusheel> without which we cannot ship USR.
[20:33] <dfarning> Ok, this sounds like a position for a person with deployment experience and a good overall knowledge of sugar.
[20:33] <manusheel> dfarning: Also, a note on definitions per functionality and the UI pages and backend part that is supported by that functionality. Yes, deployment experience + good overall knowledge of Sugar will be helpful.
[20:34] <manusheel> I think someone from OLE Nepal can help us get started on it easily.
[20:34] <dfarning> we need to look at 'critical features' from the point of view of a deployment support person.
[20:34] <manusheel> dfarning: yes.
[20:35] <dfarning> Yes, or someone like daniel drake.
[20:36] <manusheel> dfarning: Yes, Daniel is a good candidate for this role.
[20:36] <dfarning> ok, I'll start on that task.
[20:36] <manusheel> dfarning: I'll send you the template, and you'll get a very good idea on my expectations.
[20:37] <manusheel> dfarning: Thank you. Appreciate your support.
[20:39] <dfarning> how about setting up reoccuring status meetings?
[20:39] <dfarning> should we start holding those or is it too soon?
[20:40] <dfarning> Luke will be joining us in a few minutes.
[20:40] <manusheel> dfarning: Sure. Status calls are important.
[20:40] <manusheel> However, they should be more on the BRD front right now. On the development front, code fixes and QA documentation would do.
[20:42] <manusheel> dfarning: Without a set of objectives, it is difficult to build timelines. My idea is to first arrive at set of BRDs. In parallel, the knowledge transfer for development should continue.
[20:42] <lfaraone> Hello, world!
[20:42] <manusheel> lfaraone: Hi Luke.
[20:42] <dfarning> ok, how about 8am (boston time) checkins
[20:43] <dfarning> hey lfaraone
[20:43] <manusheel> dfarning: 8:00 am to 9:00 am will be a good time.
[20:43] <dfarning> just want to make sure you and manusheel touch base.
[20:44] <manusheel> dfarning: Thanks David. lfaraone:  Wish to ask you whether 8:00-9:00 am, Boston time works well at your end.
[20:44] <lfaraone> manusheel, dfarning, agreed re time.
[20:44] <manusheel> lfaraone: Great.
[20:44] <dfarning> manusheel, ok I schedule that slot for seeta cordination/ work.
[20:45] <manusheel> dfarning: Thank you.
[20:45] <dfarning> Ok, I think we have the stratigc stuff done, so I will step aside and let you and luke work through implemation issues:)
[20:45] <dfarning> thanks for everything.
[20:46] <lfaraone> awesome. I sent both dfarning and manusheel a google calendar item.
[20:46] <manusheel> dfarning: Thank you so much.
[20:46] <manusheel> lfaraone: That would be great.
[20:46] <manusheel> lfaraone: Can we begin meetings starting tomorrow?
[20:46] <lfaraone> manusheel: sure.
[20:47] <manusheel> For the first set of days, it will be both of us, who will arrive at a plan. Then, we'll get the developers in.
[20:48] <manusheel> lfaraone: Great. Let us meet tomorrow at 8:00 am Boston time. The agenda of the meeting will be getting started on the development of Sugar, method for submitting patches and reviewal, and methods to walking through the Sugar code.
[20:48] <lfaraone> manusheel: seens sensible.
[20:48] <manusheel> lfaraone: Thank you.
[20:50] <manusheel> lfaraone: Great. Talk to you tomorrow. Have a nice evening.
[20:50] <lfaraone> manusheel: after June 17, things will be a bit up in the air for the next week as we have to deal with final exams in my school, but after June 23 I'll be more free.
[20:50] <lfaraone> manusheel: you too.
[20:50] <manusheel> lfaraone: Is it June 23? Or, May 23?
[20:51] <lfaraone> manusheel: June.
[20:51] <manusheel> Caroline: We'll send you the meeting logs on our discussion.
[20:52] <manusheel> lfaraone: Sure. Thank you for informing about it at this juncture. We'll make plans accordingly.
[20:55] <manusheel> lfaraone: Neat. So, as discussed, we'll work out a plan on three areas as discussed above. We might have to do in documentation to prevent us from mentoring the same things to different set of developers. I almost through with preparing the template for these three areas. Will send it to you before the meeting.
[20:55] <lfaraone> manusheel: okay. for documentation, do you want to host it on the Ubuntu wiki, the Sugar Labs wiki, or somewhere else?
[20:57] <manusheel> lfaraone: I'll let you know about it by tomorrow. Will evaluate what would be a good idea from the expansion standpoint.
[20:58] <manusheel> lfaraone: In any case, I would prefer to use Mediawiki at this juncture.
[20:58] <manusheel> lfaraone: We have a number of good extensions been developed for Media wiki.
[21:03] <manusheel> lfaraone: Great, Luke. We'll touch base at 8:00 am, Boston time tomorrow. Talk to you soon.