Oversight Board/2008/Log-2008-08-01

• Now talking on #sugar-meeting
• Topic for #sugar-meeting is: The meeting channel for the sugar developers (sugarlabs.org) | see also #sugar | meeting time: thursdays 17.00 UTC
• Topic for #sugar-meeting set by erikos at Wed Jun 4 07:36:15 2008

<erikos> i am here

• morgs too

<walter> me too.

<walter> shall we get started?

<erikos> marcopg, ?

<marcopg> hey

<marcopg> cjb around?

<marcopg> bemasc doesn't seem to be around

<erikos> yeah he is neither in #sugar

<erikos> and tomeu is already on his way to inner portugal

<walter> Land of the Classmate II

<erikos> yeah :)

<walter> Let's start with a review of outstanding issues from last time.

<walter> the minutes are in the wiki: http://sugarlabs.org/go/Sugar_Labs/OversightBoard/Minutes

<marcopg> ok

<walter> As I recall, I was suppose to ask the infrastructure committee to report back.

<walter> They did. I included their report in last weekend's Sugar Digest

<walter> The gist is Solarsail is up and running

<marcopg> yeah we are good there

<marcopg> we just need to figure out the second box

<walter> I have a call with AMD after this meeting to ask them about that

<erikos> oh nice

<marcopg> cool

<marcopg> what about SFC?

<walter> If they cannot provide a server in a timely fashion, I'll ask one more time at OLPC

<marcopg> did they give feedback=

<marcopg> ?

<walter> That is the second topic I was to follow up on

<walter> I have had some email back and forth with Karen

<walter> She apologized that she has been slow getting back to us

<walter> She'll have something early next week.

<walter> Also, some feedback regarding trademarks

<walter> I worry a little that SFC is not going to be able to as responsive as we need them to be in the early days of the program

<walter> But I think we need to stay the course

<marcopg> yeah :/

<marcopg> ok

<marcopg> what about election process?

<walter> The other thing I did was to follow up with Mako regarding the election software

<walter> I started putting together a ballot, but realized I need a list of candidates first

<walter> I plan to solicit them from the community this week and hold the election beginning next week.

<walter> Sound OK?

<walter> Or is one week too short of a window?

<erikos> the list for the people of the commitee right?

<marcopg> maybe a couple weeks

<walter> the list of nominees for the oversight committee

<cjb> Morning all.

<walter> Hi Chris.

<marcopg> hey cjb

<cjb> Maybe two weeks, then?

<walter> Should I solicit nominees for all the committees at once? Or leave that for later?

<walter> I don't recall: do we elect the other committees or appoint them?

<walter> Let me check in the wiki...

<erikos> There was consensus that we begin with just Oversight and Members committees.

<walter> Yes. But it is ambiguous as to whether or not the Members committee is elected or appointed.

<walter> I cannot tell from the wording in the wiki: The Oversight Board is responsible for establishing committees as necessary.

<erikos> i think we said appointed

<walter> I'm fine with that. Makes things simpler.

<walter> Is an announcement in the wiki and to the initial members list adequate notice for candidate nominations?

<walter> I would think so.

<walter> I only worry one week may be tight as many people are on vacation/traveling this time of year.

<erikos> sure - you can as well leave a note in the digest

<marcopg> it sounds fine to me, but one week seems too short yeah

<walter> How about nominations close on the 16th and the election begins on the 17th and runs until the 30th?

<marcopg> that sounds good

<erikos> that should be enough

<walter> OK. If people have further thoughts on this, just let me know.

<walter> I'll get the word out and we can get past this hurdle.

<walter> I think that was all the business from last time.

<walter> Are those who were here OK with the minutes?

<walter> I included the transcript of the chat, or at least all that I managed to capture, so I think we are pretty complete

<cjb> Yup.

<marcopg> what about the logo?

<marcopg> there has been any movement on it=?

<walter> Good question.

<walter> I had given some feedback to Luca and Franco; they were going to work on the fonts

<walter> But I haven't seen an update.

<walter> I think that we are pretty close.

<walter> We do need to move quickly, as OLPC has asked that we remove our current logo

<walter> Their lawyers say we are infringing on their trademark

<marcopg> huh

<erikos> http://sugarlabs.org/go/DesignTeam/Logo-ideas#Designs_by_Luca_Ferrari_and_Franco_Lodato

<walter> they know we plan to change it, so they aren't being too aggressive about it

<erikos> there have been some edits it looks like

<cjb> (I guess our current logo has an XO and "Sugar". Are they claiming ownership of both at once, or one or the other?)

<walter> I don't think we have any problem using XO in the interface, just the logo for Sugar Labs

<cjb> cool, okay

• erikos likes this one http://sugarlabs.org/go/Image:Luca-logo-3.jpg

<walter> Erikos: I didn't see any new edits to the logos. Just the changes I made as feedback to Luca.

<erikos> walter, could be that i did not see them all last time

<walter> I think we have reasonable consensus on the overall direction and we should leave the final details to the pros.

<walter> I have to say their space-age typography has grown on me somewhat.

<walter> I thought the little color gimmick I did with fructose and sucrose was cute, but I don't know their thoughts.

<walter> So, I think we are ready to jump in to the more meaty topics?

<erikos> yup

<marcopg> yeah

<erikos> walter, you said you made some progress on trademarks?

<walter> The topics that are really pressing I think are the relationship between the engineering needs of OLPC and the long-term goals

<walter> and the relationship to the learning community

<walter> They are all somewhat related in my mind, even though they are different agenda items.

<walter> Let me explain:

<walter> OLPC has immediate needs regarding the 500K machines in the field; Sugar Labs of course should be responsive to these needs since OLPC is the only deployment of Sugar of any significance

<walter> That said, the learning community as a whole currently has little access to XOs, so if they are going to have a chance to explore Sugar, it is likely to be on off-the-shelf hardware

<walter> Old machines in the classroom or an old laptop at home

<walter> I think it is really important that we make it easy for teachers et al. to try out Sugar

<marcopg> there is also the problem of who move forward sugar development

<erikos> walter, focusing on getting packages in ubuntu/fedora should be a good start or?

<marcopg> implementing new features for example

<walter> I don't think the current live CD /USB options are mature enough to the casual user

<marcopg> because OLPC is busy with much more critical problems at the moment

<marcopg> and has no resource, say, to implement the full Journal vision

<walter> All of this is at odds with the long-term development goals in terms of our limited resources

<marcopg> I agree about live cd...

<walter> To my mind, getting something simple and stable into a package that is easy to explore on a trial basis in a conventional laptop is critical to the growth of Sugar

<marcopg> how do we resource that work though?

<marcopg> we need someone focused on it, if we want it to get mature enough

• bemasc (n=bens@c-24-62-4-169.hsd1.ma.comcast.net) has joined #sugar-meeting

<cjb> I'm not even sure that resourcing is as much the problem as knowing what we want

<walter> I don't get the feeling OLPC is interested in this direction.

<cjb> We made a pretty big push for Sugar packages in distros, and it has happened -- volunteers worked on Debian, Ubuntu and Fedora packages

<walter> The recent edict to make a "dual-boot" KDE/Sugar machine is some of my evidence.

<walter> The Ubuntu/Debian/Fedora push is very important

<erikos> i think people in 1cc think that sugar is doing ok

<erikos> and that we don't need more ressources

• bemasc is sorry to be late; has to borrow neighbor's wireless until Wednesday

<cjb> erikos: didn't you interview a new Sugar developer this morning? :)

<erikos> cjb, i would probably have not if i would get all the private messages :/

<erikos> cjb, but details are not subject here - sorry should not have started

<marcopg> cjb: hiring a Sugar developer is something OLPC wants to do, but clearly not a top priority

<marcopg> which I suppose means we need to find ways to resource the work OLPC is unable to

<erikos> marcopg, thanks for putting it in better words

<cjb> marcopg: I think we can say definitively that there will be work Sugar Labs wants that OLPC won't be willing to resource, and we should talk about how to handle that. I'm not convinced yet that it's fair to say that OLPC doesn't want to give any more resources to Sugar.

<cjb> We're clearly trying to hire, it's just been very slow. We put an offer out to W, but he didn't accept.

<marcopg> cjb: I didn't say that. Just that it's not top prio

<cjb> marcopg: erikos did

<erikos> cjb, i meant to say that it is not top prio

<marcopg> (probably he didn't mean to, he is just a little pissed off :P)

<marcopg> and well this KDE thing pisses off quite a bit

<walter> So, the bigger question is divergent priorities between Sugar Labs and OLPC.

<marcopg> mainly because we are not informed about it

<marcopg> and we get to know by external people

<marcopg> (but this is an OLPC discussion, so I stop it)

<cjb> marcopg: It was in a techteam thread yesterday

<walter> marcopg: This is a Sugar Labs discussion.

<marcopg> cjb: which one?

<erikos> marcopg, about double boot

<marcopg> q

<cjb> marcopg: from Kim, buried in the SW-ECO thread last night

<bemasc> I suspect that the people talking about this don't particularly mean "KDE" and would be just as happy with XFCE.

<marcopg> I will read it

<marcopg> is this about G1G1 or about schools too?

<walter> Let's not dwell on the KDE details. I only bring it up to suggest that the changing priorities of OLPC make it difficult for us to make long-term plans

<cjb> marcopg: also, we shouldn't think of Walter as an "external person". He's trusted by OLPC to hear their long-term plans, which is why they tell him stuff like this, and it's not the same as having broadcasted it to the world.

<cjb> bemasc: agreed

<cjb> marcopg: G1G1

<cjb> marcopg: it's to reduce G1G1 support queries by people who aren't patient enough to work with Sugar

<marcopg> happy to know that olpc still consider walter an internal person :)

<walter> I still think we need to "contract" some architectural work in several areas to address the reasons why Sugar "sucks"

<bemasc> I've been advocating for some time that, rather than attempt to make Sugar run all legacy applications, we should provide a separate legacy environment

<marcopg> cjb: ok that's good to know

<walter> bemasc: you and everyone else. But the that is not the point here

<marcopg> someone needs to do that work

<marcopg> being it design or just implementation

<walter> Can we agree to disagree about the need to architect our software goals?

<bemasc> of course

<bemasc> Is there a concrete decision we are trying to make? Perhaps I missed it.

<walter> I don't know how we make progress on, for example collaboration, without an agreed upon framework. The disconnect between Scott's piece in the wiki and Greg's document from a couple of days ago is dramatic.

<cjb> I think we probably just mean different things by architect. At the moment everyone's just fire-fighting, so there are many aspects of architecture (blue-sky design, seeing changes through from design to implementation, ..) missing.

<marcopg> and collabora plans too, likely

<walter> I would like to have someone write down the goals--a la the bitfrost document--and they we can have the community fire away

<walter> But it is a rudderless exercise right now.

<bemasc> the bitfrost document remains essentially unimplemented

<walter> As someone -- was it Poly -- pointed out, there is no decisionmaking process.

<bemasc> also, while I have high regard for the Bitfrost design, it is essentially a listing of how to do secure containerization using vserver

<walter> Bitfrost is largely unimplemented, but we aren't spinning our wheels deciding what are goals are.

<cjb> bemasc: -EOFFTOPIC :)

<walter> Is the word vserver even mentioned in the Bitfrost spec?

<cjb> ...

<walter> If we could agree on the high-level goals, we could have a better chance of unleashing the community to take action.

<bemasc> what I'm trying to say is, Bitfrost is a helpful guideline, but it's not a brand-new blueprint for security architecture

<bemasc> it's just a thin metaphor over vserver

<erikos> we might want to go back o the topic: how do we implement the parts not interested by OLPC

<marcopg> I'm skeptical the community will take action on the base of a spec

<cjb> erikos: step 1: by specifying what they are and why they're important

<marcopg> we need someone to lead the implementation of these components

<walter> Bitfrost is not a spec, true. That is fine in my book

<marcopg> and do it in a way that the community can be involved in

<walter> Yes. Yes.

<erikos> +1 to what marco said

<walter> If we agree to the goals, then, for example, we can say to Poly: if there are so many superior algorithms that meet these goals, then put one forward.

<bemasc> I agree. The only way to pick winners in an open project is to pick the spec that has been implemented

<walter> But without an agreed upon goal, we cannot measure results

• unmadindu (n=sayamind@gnu-india/admin/unmadindu) has joined #sugar-meeting

<walter> So maybe it is a matter of semantics, our disagreement.

<walter> I think we were very close to finalizing a set of goals and overarching designs for the Journal/datastore in January.

<cjb> cool!

<cjb> what's happening in January?

<bemasc> cjb: no, January 2008

<cjb> oops

<cjb> I thought s/were/are/

<bemasc> the Datastore Summit

<cjb> Yes, the Datastore Summit

<marcopg> I guess my point is that even once the requirements are clear, you still need someone to take care of doing most of the implementation

<cjb> that didn't go very well, because there were only a few people there and the discussion remained private

<walter> If Scott had time to come up for air, he could probably pull all the pieces together quickly for the community to take over (with help from Tomeu, ofcourse)

<bemasc> Ivan was apparently tasked with drawing up a detailed design document, and then everything fell apart

<cjb> I don't think Scott was *at* the datastore summit

<marcopg> we can't hope the community will step up to implement complex components like the datastore

<walter> I don'

<marcopg> he was not

<walter> I don't think a private planning meeting is a bad thing. It is fine if the results are made public for vetting. If wasn'

<marcopg> Ivan was supposed to spec what we agreed at that summit

<cjb> marcopg: depends how you look at it. I'd claim that Federico is working on doing it :)

<walter> t an edict, like KDE

<marcopg> and get larger feedback

<erikos> marcopg, i guess the community can do the 'simpler tasks' to free the other devs from doing them

<marcopg> but it didn't happen

<marcopg> heh

<walter> It is that things like that slip between the cracks that is the problem.

<cjb> http://www.gnome.org/~federico/news-2008-07.html

<cjb> GNOME's thinking about a document-centric desktop

<walter> The day-to-day firefights tend to dominate people's time; hence my proposal to dedicate some people to wrapping these things up.

<cjb> something we could do is try to make sure we can influence their thinking so that the result could be used by sugar too

<cjb> that would have some great benefits; we'd get compatibility with GNOME without even trying. :)

<bemasc> My feeling on the datastore is maybe a good example of why I'm resisting the push for an architecture document. I think it would be better to implement a simple versioning datastore that's backwards-compatible with the current API. That seems quite easy to me. We can move incrementally from there.

<marcopg> cjb: yeah we should try to get involved in that

<cjb> (we're == OLPC)

<bemasc> I agree that most of Sugar's technologies (isolation, central document store, versioning, pervasive collaboration) are a natural fit for a next-gen Gnome.

<walter> I think that if we had a document, then we could assess your proposal and perhaps quickly agree to it.

<walter> I think if we had a set of clear goals, we could quickly assess your assertion and probably agree to it.

<cjb> here's some of the stuff people have been doing in GNOME:

<cjb> http://www.iola.dk/nemo/blog/?p=3

<cjb> so, time-centric rather than folder-centric, has labels/categories, things like that.

<walter> For what it is worth, when I spoke to Stormy yesterday from the Gnome foundation, she promised whatever cooperation she could muster.

<cjb> maybe we should take an action item for someone (maybe dfarning?) to make contact with the people who've expressed interest in the GNOME datastore work

<walter> If we could agree on what we are looking for, we could probably leverage their work.

<cjb> right

• morgs concludes first meeting of #ubuntu-sugarteam

<cjb> and I think the work's happening right now, so it would be a good time to introduce ourselves and share ideas

<marcopg> I'm not sure what you would like to see in such document yet

<marcopg> morgs: wow!

<erikos> morgs, congrats!

<bemasc> I asked the GVFS people, and it sounds like GVFS is very focused on the standard filesystem approach, and so not of much use to us in its current form.

<morgs> :)

<walter> morgs: cool

<marcopg> the requirements? or the implementation details for these components?

<walter> The meta issue again is how to get the resources pulled together to be able to define and agree upon these questions

<bemasc> ok

<bemasc> I'm beginning to understand this discussion correctly.

<bemasc> So the obvious thing that can happen is: someone with an architecture plan can write it up on the wiki and solicit improvements. Once it's ready, they can post it to the mailing list and say "who wants to help work on this". A bunch of people can get together, open a repository, and start coding. After it's working, they can ask the gatekeepers (marcopg, tomeu?) to include it.

<bemasc> The question is: is there something we should do to help this process along, such as blessing a particular proposal or directing specific developers to work on specific tasks?

<erikos> bemasc, i think that you have to guide it a bit

<bemasc> My feeling is that Sugar Labs doesn't have any resources (e.g. $$) that allow us to make people do things they don't want to do.

<marcopg> and how do we encourage the community to do the architecture work?

• mtd proposes walter as BDFL and then we could move on :).

<erikos> bemasc, unless the interests are overlapping greatly - someone will not jump up and code soemthing like the datastore

<bemasc> marcopg: we say "Hey you! _You_ can write designs for Sugar. _Anyone_ can make designs for Sugar. Try it! We'll keep our criticism friendly."

<cjb> bemasc: I think in the case of design work, it's not even that we don't want to do it, it's just that we're busy with an OLPC release for the next month.

<erikos> specing things might help to show what we are interested in - and if there are overlaps yuo can work together

<marcopg> cscott stepped up to do that work on both the datastore and network

<bemasc> I don't think we need to resolve anything more than "if you have an idea, write a spec on the wiki, and e-mail it out to sugar@"

<marcopg> but it didn't produce anything useful yet

<marcopg> why it didn't work?

<bemasc> marcopg: the network part didn't work because there are lots of people working on the network, and cscott is not their boss

<erikos> hmm i can tell you

<cjb> marcopg: I'm not sure.

<marcopg> bemasc: what about ds?

<cjb> yeah, the networking thing is a disaster. no surprises there. olpcfs seemed to be going well, though.

<erikos> marcopg, you can not only start - you need to follow up as well

<cjb> also, I contest that olpcfs hasn't produced anything useful. It's usable today, just not as a journal backend.

<marcopg> my feeling is that until you have an implementation and a maintainer

<marcopg> the spec is not very compelling to the community that needs to accept it

<bemasc> This is the open source world. Ultimately, what matters is the code.

<marcopg> cjb: what I mean, is that we are far from an agreement on olpcfs technical merits, let alone on a concrete plan to land it

<cjb> yeah. the more I think about the datastore, the more I realize that the !olpc sugar developer community is still small, and the best shot for the moment is to latch on to the GNOME people who are currently very excited about it and make sure they're working on the same goals

<cjb> marcopg: right. so, maybe that's the problem -- cscott presented it and didn't really get strong feedback saying he should land it next release, so he left it alone

<bemasc> cjb: that's really the same approach we're taking with networking. I think the next Gnome will use Telepathy+Empathy as its default IM client.

<cjb> (that's a guess, I don't know if it's actually what happened)

<walter> I think the need is both a olpcfs spec and a connection to the various components that need building

<cjb> (also, some other examples of versioned filesystems have come along since olpcfs)

<cjb> Maybe we should move on for now?

<marcopg> so what's the next step here? should we encourage people to work on the designs for both ds and network?

<marcopg> and participate actively to the discussion about this on the mailing lists?

<marcopg> I guess I don't see other ways to reach an agreement...

<walter> I think we need to be more focused than jut ask people to jump in

<marcopg> I'm fine with moving on, but I'd like to at least reach an agreement on an action item to move this a little forward

<erikos> and probably try to make it as public as possible to get feedback from other communities

<erikos> or at least that they are aware of

<cjb> marcopg: my suggestion is the GNOME contact

<bemasc> I don't think we need a network rearchitecture. Collabora is very much on the case, and Telepathy seems like the right solution to me.

<marcopg> cjb: yeah but even in that case we need to come up with a good description of our goals

<bemasc> Anyone here friends with lots of Gnome devs?

<walter> yeah. J5

<marcopg> (I guess the GNOME is lacking versioning btw, which is fundamental in our design)

<bemasc> We can organize a "user-friendly storage" IRC meeting with all the people working on these problems.

<cjb> sounds good!

<cjb> even just letting them know that we want to use their code and are happy to show them ours would be a fine outcome of such a meeting

<bemasc> How about setting a tentative date/time, publicizing it on sugar@ and devel@ and gnome lists and freedesktop.org lists and ...?

<bemasc> and also specfically inviting people we know to be working on such projects?

<marcopg> maybe stormy can help publicizing inside gnome

<cjb> I think tomeu's on vacation for two weeks or so?

<cjb> it could be after he gets back

<marcopg> yeah, one week

<bemasc> cjb: that would be fine with me

<marcopg> we could do it in a couple weeks

<cjb> okay, so tentatively mid-August

<bemasc> since it would be good to let OLPC's 8.2 work cool off a little too

<bemasc> how can we note this so as not to forget about it?

<cjb> minutes? :)

<marcopg> action item in the minutes I guess

<mtd> hmm guys the emperor has no clothes: you really expect to get a new DS from this process in the next year? via an IRC meeting?

<mtd> ...with no hiring?

<marcopg> not in the next year for sure

<mtd> oh ok

<cjb> mtd: well, this is my point too. we don't, which is why we latch onto GNOME, which has a much larger community base

<bemasc> mtd: the point is that the Gnome people are thinking about the same problems, as are the developers of Btrfs and Tux3 and ...

<marcopg> even with GNOME, it's likely to take years

<marcopg> if we want immediate action, there is no other way then hiring imo

<cjb> of course.

<mtd> right, ok. So basically we should stop worrying about it (besides agitating for upstream) and focus on other stuff? So no more "the DS sucks" distractions?

<cjb> I'll go with that.

<bemasc> mtd: I disagree. I think we also need a simple, short-term DS replacement.

<walter> sorry... I was on the phone with AMD and only half in the discussion

<walter> They'll try to get us a server.

<bemasc> That was actually scheduled for 8.2, and then dropped.

<marcopg> yeah agree with bemasc

<walter> I need to send them a spec

<marcopg> we should incrementally improve the DS

<marcopg> while a better system is being cooked, hopefully with the larger GNOME community

<cjb> marcopg: I guess I'm saying that I don't think it'll take much for a GNOME ds to become better than our current one.

<cjb> and that we're at a critical point in our opportunity to shape their work so that we can use it.

<bemasc> oh, I found the incomplete datastore redesign stuff: http://wiki.laptop.org/go/Category:DatastoreRedesign

<walter> I don't remember why we dropped DS refresh from 8.2

<marcopg> cjb: I should look more into what they have right now to say that

<marcopg> cjb: in particular I'm not sure about versioning

<walter> was it because we didn't think we could complete it in time (and test it)

<bemasc> I think it just fell off the stack

<marcopg> we could punt on versioning until it can be done as part of the GNOME thing, I guess

<cjb> (we didn't do that, though)

• bemasc still doesn't like olpcfs

<bemasc> It would be helpful if the OLPC devs kept an explicit public work-queue, but that would also be tremendously invasive.

<marcopg> my suspect is that the GNOME thing is just based on a normal filesystem

<marcopg> which gives great compatibility

<cjb> bemasc: I think it would too depressing to see "June: Firefighting. July: Firefighting."

• dirakx (n=rafael@190.156.106.187) has joined #sugar-meeting

<marcopg> but also limits quite a bit the features you can get

<bemasc> cjb: true

<cjb> marcopg: well, we have the chance to tell them to use a db instead

<marcopg> it's an enanched file manager, not an enanched file store

<walter> We shouldn't debate the details here, but what is the agreed upon action plan?

<marcopg> yeah

<walter> And for the network?

<unmadindu> the initial code for nautilus seems to be at http://gitorious.org/projects/nautilus/repos/mainline

<walter> And for our LiveCD strategy?

<cjb> walter: we'll pick a date to hold an IRC meeting about document-centric storage. We'll ask you to use your contact with Stormy to publicize it to the GNOME community at-large, and we'll invite some key people by hand.

<marcopg> for the datastore I think we should take the time to look into nemo

<marcopg> and try to organize an irc meeting with all the people interested

<cjb> I guess I'm about to say something controversial: I don't think networking has much to do with Sugar

<cjb> I'd certainly put telepathy outside the Sugar stack

<walter> cjb: I agree with you, but the fact that collaboration is so important to Sugar...

<cjb> that doesn't mean Sugar shouldn't have networking APIs -- the presence service is a good example of one, it says "once you know how you want to communicate presence, you call this add_buddy() function and I'll show it on the screen"

<marcopg> perhaps, but we need to ensure Sugar has a good collab framework it can use

<walter> and the fact that it is so unstable and unpredictable...

<cjb> but it does mean that the primary problems with networking right now aren't really Sugar's fault, or Sugar's area to fix

<marcopg> personally I'm fine with collabora keeping to cook it

<marcopg> and confident they will slowly get there...

<walter> means that we cannot rely on it

<bemasc> cjb: this is a taxonomy problem, of course.

<marcopg> collabora is also working with GNOME a lot

<walter> I agree that power management is not a Sugar problem...

<marcopg> which bring us in the same good direction as trying to coordinate with them about the ds

<bemasc> power management is not a Sugar Labs problem, at least not a big one.

<mtd> cjb: you're right. I think what's just been argued about the DS could be argued about collab.

<walter> well, I suppose if there is nothing we can do, we should focus on what we can fix: DS, tc.

<marcopg> tc?

<walter> etc.

<marcopg> oh :)

<walter> I cannot seem to type today :(

<marcopg> yeah I'd say to start from the DS

<walter> I want to return to the boot image question for a moment

<bemasc> good

<cjb> I think there's great potential for working on DS with the GNOME community. It'll introduce us to them, could engage a lot of their developers with Sugar.

<walter> it is critical to getting people to try Sugar in the field

<walter> apt-get sugar (or yum install sugar) is great, but not good enough yet for those not on the bleeding edge

<marcopg> do we have agreement on what we need there?

<bemasc> morgs: ubuntu seems like a great platform for Sugar LiveCDs. Are there people on your team interested in producing them?

<marcopg> did you see the appliance someone at rh is working on?

<marcopg> bemasc: so is Fedora :P

<bemasc> marcopg: I could not figure out what "appliance" means in this context. It seems to be a Fedora-specific term.

<walter> morgs: I agree, but for example, I have a friend in Kenya right now, running ubuntu in schools, and he cannot get Sugar to install...

<walter> he needs to upgrade too much stuff for his network capacity

<erikos> bemasc, heh have problems with it as well

<marcopg> bemasc: http://www.vmware.com/appliances/

<bemasc> yuck, vmware

<marcopg> oh it doesn't use vmware

<marcopg> was just an example of the same concept outside Fedora :)

<bemasc> I am still intrigued with the possibility of using Ubuntu's Wubi with an Ubuntu Sugar livecd

<walter> It seems we are close along any number of fronts. This may be a place where the community could jump in, perhaps the ubuntu-sugarteam could take a leadership role

<walter> I am not familiar with Wubi

<bemasc> Wubi runs a complete linux VM under Windows

<marcopg> the Fedora/OLPC interest group seem to be working well

<marcopg> perhaps we could get quite a bit of help from them on this one

<marcopg> but anyway

<walter> Between the two, if we could really make it plug and play...

<bemasc> Wubi would be great for getting Sugar onto existing Windows-based desktops in schools

<marcopg> I would like to understand what we are aiming to

<cjb> walter: the idea would be that rebooting into a livecd is a lot of disruption, and popping up a Sugar window on their Windows machine would make it a lot easier.

<walter> the other question is configuration of these machines.

<marcopg> is a well working livecd what we need here?

<walter> the network for sharing, etc.

<bemasc> marcopg: yes, that would be great

<marcopg> or liveusb, which gives you rw

<bemasc> marcopg: that would also be great

<bemasc> we really need all these things, and we need them kept automatically up to date

<marcopg> I have that working for Fedora...

<walter> Liveusb is attractive: we could give them away at education summits

<marcopg> the thing is that we need someone with enough time to make it work well

<cjb> well, there's the fedora-olpc-list now

<walter> I think this is a matter of being organized more than anything else...

<marcopg> and to ensure it always have the latest versions etc

<walter> the community can do this!!

<marcopg> sure

<marcopg> here the community can really be a lot of help

<marcopg> if you look at the applicance thread

<walter> Would Dennis be the lead in the Fedora community?

<marcopg> there are people already that are trying to make it work

<bemasc> This is a great task for new arrivals from the outside world. I'm perfectly happy to push parallel Fedora- and Ubuntu- based efforts

<marcopg> not that with the same config as the appliance

<marcopg> you can also generate liveusb and livecd

<marcopg> s/not/note

<walter> cool

<cjb> walter: I think Greg DeKoeningsberg would do a great job, actually

<marcopg> yeah

<bemasc> So how do we push this?

<walter> Maybe I should contact Greg DeK.?

<cjb> (in case people didn't know, Dennis is moving from OLPC to Red Hat. He'll still be around a bit.)

<cjb> walter: yup, sounds great

<marcopg> perhaps we ask gdk to push it in fedora

<cjb> walter: he'll be in Cambridge next week or the week after next or so

<marcopg> and morgs can help out on the ubuntu side

<walter> I didn't know Dennis was leaving. He's been a great help.

<cjb> walter: you should get on his timetable :)

<erikos> walter, yeah sadly he is - but he has suggested a replacement already

<cjb> and Red Hat's particularly friendly to OLPC at the moment :)

<walter> that is a good change in the wind

<walter> so it seems we have a plan for liveCD/liveusb/appliance etc.

<walter> this will help with our outreach efforts

<walter> other topics for today?

<marcopg> yeah

<cjb> I wonder if we should talk about Portugal at all

<walter> I pinged Intel on this.

<walter> They said they'd get back to me.

<walter> But who knows.

<cjb> *nod*

<walter> Anyway, isn't Tomeu handling this while he is on holiday :)

<erikos> hehe

<cjb> ah, infiltrating from within, cunning.

<walter> I think Intel (like OLPC) is taking an attitude that they'll give the customer whatever they want

<walter> Windows, Linux, KDE, Sugar, etc.

<marcopg> so we just need to convince their customers that Sugar is better :)

<walter> But we need to make sure Sugar is on the list at a minimum

<walter> The trick with Intel is the incentive to their Sales force.

<marcopg> the award winning UI! :)

<bemasc> deploying Sugar on a non-XO device is going to be fairly tricky

<erikos> walter, i only hope - that this means as well that they keep on supporting sugar

<erikos> walter, and not just outsource that whole part

<walter> bemasc: we need to exactly how so

<bemasc> at a minimum, Networkmanager will have to be reconfigured substantially, the power management stuff will probably have to be removed... and I'm not even talking about resolution independence.

<bemasc> also, OLPC has little incentive to support this sort of work

<cjb> bemasc: s/little/no/

<marcopg> bemasc: what probs do you expect with NM?

<bemasc> marcopg: mesh

<cjb> but that's okay, because the work isn't that hard.

<marcopg> I mean the current nm supports normal access points just fine

<walter> mesh on the Intel platform is Intel's problem, but collaboration through AP works out of the box

<walter> and works in a way that is compatible with the XO

<cjb> bemasc: install Fedora 9, yum install sugar, run it, fix bug, repeat.

<bemasc> marcopg: the question is whether NM will correctly recognize that there is no mesh device, and if that recognition will propagate correctly up through the UI

<cjb> bemasc: it clearly does so on Fedora 9.

<marcopg> bemasc: yeah

<walter> I think most of the resolution issues are covered at this point

<cjb> oh, you're worried about spurious mesh circles in the UI. Well, that might happen.

<cjb> but it's not like it crashes :)

<marcopg> resolution is some tricky/not fun work, but should not take too much

<marcopg> not sure which pm stuff you are referring to

<walter> I notice few if any anomalies when I run on my non-XO

<cjb> bemasc: to elaborate on s/little/no/, I think after an OLPC-Sugar Labs split, porting to new platforms is one of Sugar Labs' main purposes, and becomes not part of OLPC's purpose at all.

<marcopg> but well that guy is picky :P

<marcopg> cjb: certainly

<bemasc> cjb: right. Ideally, Intel would fund the port.

<cjb> I don't mean that OLPC doesn't gain anything from it, though. It's in everyone's interest for more people using Sugar and writing activities.

<walter> I think they (Intel) and others need to kick in.

<marcopg> there are several little things which are XO specific

<marcopg> but in general I expect it to not be a bunch of work

<cjb> (it also mentioned Windows)

<marcopg> oh yeah seen that one

<walter> Where was it published?

<walter> the bid?

<walter> I've never seen it.

<cjb> It was linked from olpcnews, will find a URL

<walter> We should probably wrap up soon.

<cjb> http://www.latu.org.uy/portal/page?_pageid=514,1&_dad=portal&_schema=PORTAL

<cjb> http://www.olpcnews.com/countries/uruguay/ceibal_project_progress.html

<walter> I'll write up the notes

<walter> cjb: thanks.

<cjb> thanks!

<cjb> the bottom link on the latu page is the Sugar job, and there are two PDFs, the particulares PDF:

<erikos> thanks

<cjb> > Se verificará que la interfaz desarrollada pueda ser instalada y correr al menos sobre las

<cjb> variantes del sistema operativo Linux DEBIAN y FEDORA.

<cjb> > Se verificará que la interfaz desarrollada pueda ser instalada y correr al menos sobre los

<cjb> equipos XO, Classmate PC, Asus eee .

<walter> I think the action items are the (1) election; (2) the server; (3) the logo; (4) gnome outreach for the DS; (5) outreacht o ubunutu and fedora re liveCD

<walter> anything I missed?

<cjb> sounds good.

<marcopg> good

<cjb> it really would be excellent to Sugar on Portugal's laptops, although there's no specific action item :) It'd be worth e.g. a plane ride to show them what we can do.

<cjb> s/to/to get/

<marcopg> yeah

<marcopg> sounds like we should try to be active on that front :)

<walter> We need to find out who are the decision-makers. I don't know if Intel will invite us...

<walter> I'll push for it.

<walter> Thanks everyone for participating today.

<marcopg> thanks!

<walter> Please make suggestions for new topics in the wiki.

<erikos> ok thanks!

<walter> Have a good weekend

<walter> Chris, get to the Go Club!!

<cjb> ;-)