Web   ·   Wiki   ·   Activities   ·   Blog   ·   Lists   ·   Chat   ·   Meeting   ·   Bugs   ·   Git   ·   Translate   ·   Archive   ·   People   ·   Donate

#sugar-meeting, 2010-03-05

Index | Today     Channels | Search | Join

All times shown according to UTC.

Time Nick Message
11:04 bernie present... (but not for long)
11:04 mchua here
11:05 walterbender since Sean is not here yet, let's start with the ASLO discussion.
11:05 #topic bundle policy on ASLO
11:05 Has everyone been following alsroot's thread?
11:06 mchua nods
11:06 tomeu is not uptodate
11:06 mchua looks for list thread to #link in
11:07 walterbender the gist is, right now we don't have a great way of supporting bundles with binary dependencies and it is causing some confusion in ASLO.
11:07 bernie walterbender: I did
11:07 walterbender So the question alsroot posed is do we want a policy where by we ban such mixed bundles or ignore the problem or defer the problem until we have a suitable solution.
11:07 mchua #link http://lists.sugarlabs.org/arc[…]March/022800.html
11:08 tomeu doesn't have time to read it today :/
11:08 mchua The request from Aleksey as originally phrased: "Can activity bundles on Activity Library [1] be not fully bundled and demand additional (except having .xo) steps (that in most cases will demand network connection) to its launch."
11:08 walterbender alsroot: put a specific proposal for our consideration in the agenda in the wiki: http://wiki.sugarlabs.org/go/O[…]ght_Board/Minutes
11:09 tomeu well, I guess the policy should match the intended design?
11:09 walterbender there are of course technical considerations, but there is a policy issue underlying this, hence the SLOBs request
11:10 IMHO, bemasc's post was the most relevant to framing our policy discussion:
11:10 If Sugar is working as intended, 99% of Activities will be crap.  This is
11:10 because the purpose of Sugar is to invite novices to engage actively in
11:10 software development.  Novices make bad stuff, and we want to install and
11:10 run that stuff.  This means we can't rely on any transmission medium that
11:10 requires human approval.
11:11 I that spirit, I think we want to open things up as much as possible...
11:11 but we don't want to compromise stability...
11:11 mchua #link http://idea.olpcorps.net/ideat[…]atorrent/idea/20/
11:11 has two proposals + poll results.
11:12 wants to thank alsroot for his work in bringing this discussion up and gathering the evidence, btw - it's a lot of work
11:12 walterbender +1
11:13 bernie walterbender: re-enabling rainbow would help
11:13 walterbender bernie: yes... I don't know the status
11:13 bernie walterbender: I have this on my todo list, btw... but I don't know if and when I'll ever get around to do it... there's too much work to do here.
11:13 alsroot well at the end request wasn't about quality of activities but about having non-SP deps
11:14 bernie walterbender: we are "almost there", according to m_stone. rainbow is packaged in fedora and sugar patches were committed... but there's some integration work to be done
11:14 alsroot: right
11:14 mchua alsroot: are the 2 options on http://idea.olpcorps.net/ideat[…]atorrent/idea/20/ still the ones we're considering and debating between?
11:15 thinks that's about right, but wants to be sure
11:15 alsroot mchua: at least in my mind there is a fork and we have to explicitly follow one of directions -- imho
11:15 mchua agrees
11:16 walterbender alsroot: agreed and maybe being open to novices is orthogonal to the question, but I think it suggests we want to be as open as possible... Solution #2
11:16 alsroot walterbender: well "being open to novices" could mean being open to java novices
11:17 walterbender if we have a mechanism for local caching of ASLO, then the fetched on demand problem is diminished
11:17 alsroot e.g.
11:17 mchua agree with the "as open as possible" - the best solution will win
11:17 cjb walterbender: the package being fetched will probably not come from ASLO.
11:17 for example, ASLO does not contain a JVM
11:17 bernie I will have to drop off the meeting soonish
11:17 mchua if people care about making something possible, making it easy for something to work, they'll make the tools and docs that allow novices to get involved with $their_platform; I see no need to block that
11:18 walterbender cjb: well, maybe the key is that we facilitate local caching of dependencies, regardless of where they originate
11:18 cjb walterbender: so, we're talking about generic distro dependencies, not merely other-activity-on-ASLO dependencies.
11:18 mchua We may want to make a stronger statement about support (or lack thereof) so that everyone's clear that allow != support.
11:18 bernie cjb: we also would like to have inter-activity dependencies, I guess
11:18 cjb: think Gcompris
11:18 cjb maybe, yeah.  we're not very close to an actual technical proposal yet.
11:18 walterbender or even Etoys
11:18 cjb bernie: yes, of course; that's the easier part.
11:19 bernie walterbender: or turtle art activities :)
11:19 alsroot cjb: but we are trying to solve next questions, in my mind we can ask only on request and going further and discuss possible tech implementations
11:19 s/ask/answer/
11:19 cjb I think we probably all agree that #2 is where we'd like to be, as a strategic decision.  I don't think we should enact any policy that takes us into that world until the technical issues with dependencies are all sorted out, though.
11:20 walterbender cjb: I think that if we endorse the openness policy, it will help inform the tech. work
11:21 mchua Do we need a motion to be clear that we want to go in the #2 direction (is anything specific being blocked by not having a motion passed right now)?
11:21 alsroot cjb: but my original concern was about Agenda items's #1 issue, in my mind if we will continue to follow existed scheme we will get a heap of binary crap instead of ASLO
11:22 walterbender alsroot: it seems the only way to make it less fragile until we have a solution is to ban binary bundles...
11:22 but I think that is extreme
11:22 alsroot walterbender: yup, like http://thread.gmane.org/gmane.[…].olpc.sugar/21243
11:22 walterbender a boldly displayed warning ...
11:23 alsroot oops sory, wrong link
11:23 cjb I agree with walterbender.  These problems with the .xo format aren't new; we've been trying to work out how to improve them for years.  It doesn't make sense to start banning them now.
11:23 walterbender I kind of liked the .x0 idea :)
11:24 alsroot cjb: did we have ASLO(deployment agnostic tool) two years ago? I guess nope
11:24 walterbender so let me try to make a motion
11:24 alsroot in case of OLPC this problem is not so critical
11:25 the right link about restrictions is http://article.gmane.org/gmane[…].olpc.sugar/21244
11:26 tomeu rather than seeing one or another solution as problematic, I see it as if each known solution handled better a different set of use cases
11:26 walterbender alsroot: I think experimental is the wrong label... GCompris is not experimental
11:26 cjb I guess I'm having trouble reconciling bemasc's post there with his later message about how he wants novice/bad activities
11:27 tomeu maybe the most important use cases have changed with time
11:27 alsroot walterbender: but it already public, so..
11:27 walterbender alsroot: I don't think it is a public vs not publc issue.
11:27 I think it is a no-external dependencies vs. you may need to download additional stuff issue
11:28 that is what we want to communicate
11:28 tomeu what I would like to avoid is focusing on improving the wrong set of use cases, thus degrading general quality of experience
11:29 alsroot tomeu: keeping in mind current situation, every explicit declaration about blobs in acitivites(including it is wrong use case) is useful
11:29 walterbender tomeu: well, it seems we have the large deployments that already can pick and choose what they install...
11:29 and then there is the user who wants an addon
11:29 orthogonal to all of this is the update problem (which is another use of ASLO)
11:30 sdziallas, who just joined us, and I discussed a few ideas about updates yesterday... but that is orthogonal to today's topic
11:31 alsroot walterbender: but we are moving to other stuff, I mean bemas's idea of moratorium for *new* blobs and implementing new scheme, is useful
11:31 walterbender tomeu: so the use case is the kid who wants to download a new activity and may or may not be successfull because of dependencies an architures
11:31 bernie walterbender, alsroot: at this time, the XO builds are fetching activities from aslo, but indirectly. they go through wiki.laptop.org because aslo does not add the required microformat tags to the activity pages.
11:31 walterbender tomeu: that determines the quality of the experience
11:31 bernie I think it would be trivial to add those tags to aslo
11:32 tomeu walterbender: sorry, I'm not ready to actually discuss possible solutions because haven't read the thread yet
11:32 walterbender so it seems we should try to immediately WARN the users...
11:32 mchua walterbender: did you have a motion in mind earlier?
11:32 walterbender and work on a solution where the experience
11:32 mchua looks at time, wonders if we want to figure out next-steps for this one so we can tackle other topics as well
11:33 CanoeBerry mchua: i'm open if this discussion is productive
11:34 walterbender mchua: w/o Sean, we cannot get far on TM anyway :(
11:34 anyway, my proposal would be to:
11:35 mchua points out we still have goals, gsoc
11:35 listens for proposal :)
11:35 walterbender (1) Bundles with non-Sugar dependencies be clearly marked in ASLO
11:36 (2) We work towards a mechanism for supporting access to non-Sugar dependencies--a specific endorsement of being open.
11:36 (3) We do not restrict ASLO while we progress towards #2.
11:36 mchua what does "support" mean in this context?
11:36 walterbender Consider that a motion...
11:37 mchua: well maybe we need to have another field: supported/not supported
11:37 bernie walterbender: yea
11:37 alsroot walterbender: btw, "restrict" means only *new* blobs not existed activities thus such restriction could be useful
11:37 mchua If it's "allow people to do it and put it on ASLO," that's one thing, if it's "provide hosting resources for them to do it" that's another, if it's "we will help you with our limited people-time-resources if things break," that's yet another
11:38 walterbender alsroot: yes... but personally, I think that is a mistake...
11:38 mchua I'm fine with the first two but we don't have the resources to do the third.
11:38 walterbender mchua: agreed... but that is true of many Python-only activities as well
11:39 mchua nods
11:39 walterbender mchua: I think we want to support Write and I am not sure we want to support, for example, Sliderule
11:39 alsroot walterbender: btw existed activities can upload blobs w/ new versions
11:39 mchua Aye. Well, the "support - what does it mean, what do we grant it to?" question is a whole different discussion, I think
11:39 walterbender so it seems a separate topic of do we want to add a support flag to ASLO and what is the polciy for settign that flag
11:40 mchua offers to write that up for next week's meeting if desired
11:40 walterbender we can tackle that next, but is there a second to my motion?
11:40 #action: mchua to write up support question for next meeting
11:41 mchua likes motion, trying to rephrase, one moment
11:42 walterbender: "Activities with non-Sugar dependencies are also allowed to use ASLO so long as they are clearly marked as having non-Sugar dependencies."
11:42 is that a shorter way of putting it?
11:42 do we need to specify a mechanism for marking?
11:42 the "we will work towards..." part is "this comes up as a topic next week"
11:43 imo
11:43 walterbender mchua: sure... but that is a tech. issue we don't need to address as SLOBs
11:43 mchua walterbender: point.
11:43 walterbender I second mchua's phrasing of the motion
11:43 mchua laptop about to run out of power and shut down
11:43 cjb mchua: I think yours might be overly concise, for someone who hasn't got all of the context already
11:43 mchua cjb: feel free to rephrase :)
11:44 cjb so perhaps a slight preference for Walter's extended one
11:44 mchua Okay.
11:44 CanoeBerry yeah
11:44 mchua My vote is +1 for either, btw
11:44 in case my laptop dies on me suddenly
11:44 cjb I'll second walterbender's, and we can always give more details if they're asked for
11:45 walterbender OK. Let's vote on "walter'
11:45 's motion"
11:45 mchua +1
11:45 battery dying
11:45 walterbender (excuse the fat fingers"
11:45 aye
11:45 CanoeBerry +1
11:45 cjb aye
11:46 walterbender OK. The motion passes...
11:46 alsroot: is that sufficient to unblock you?
11:47 alsroot walterbender: so only 2) was accpeted?
11:47 I mean w/o 3)?
11:47 cjb alsroot: not sure what you mean -- can you quote?
11:47 walter's (1), (2), (3) list were all accepted
11:47 alsroot http://pastebin.be/23817
11:48 walterbender alsroot: all three statements were part of the motion
11:48 cjb yes, all of those were accepted
11:48 alsroot ok w/ that
11:48 walterbender alsroot: I'll make it more clear in the minutes...
11:48 alsroot: I just want to make sure you are unblocked
11:49 alsroot walterbender: I am, will post going further email post to devel@
11:49 walterbender alsroot: thanks.
11:49 OK. Next topic...
11:49 #TM in brief
11:50 While I would like Sean's feedback, I modified yet again http://wiki.sugarlabs.org/go/T[…]_Trademark_Policy
11:50 bernie mchua_afk, walterbender: for the record, I would also have seconded the motion if I weren't on the phone.
11:50 walterbender I think it should capture both cjb's intentions and (hopefully) sean's
11:50 cjb oh, cool
11:50 thanks!
11:50 walterbender bernie: not to late to vote
11:51 bernie walterbender, cjb: cool
11:51 walterbender cjb, bernie: let's see what Sean thinks...
11:51 but cjb: does it address your concerns?
11:52 cjb yes, totally
11:52 mchua on phone now so can vote but not so useful for discussion
11:52 walterbender (essentially I broke 2.a into three chucks... and put two on the no permission needed side and one on the permission needed side.
11:53 OK. let's move on because Sean is not here.
11:53 #action Walter to discuss mod to TM policy with Sean...
11:53 cjb ok
11:53 walterbender #topic GSoC
11:53 this is both an update and a discussion...
11:53 update: Tim and I are talking/making headway on getting us enrolled again.
11:54 discussion: We have been thinking about a slightly different approach to projects this year...
11:55 While we'd be open to considering any proposal, we would like to encourage interns to develop projects around predefined open tickets...
11:55 mchua read proposal and i like it. useful starting point with room to move.
11:56 walterbender e.g., there are a number of open tickets in Browse... it would be great to have an intern to work on a clearing defined subset of those, and include engagement with deployments for testing
11:56 and we could ask for a patch to a more trivial Browse ticket as part of the qualification process
11:57 I think this would make the whole program more focused and more likely to see success for both the student and SL at the end of the summer.
11:57 What do people think of that?
11:58 CanoeBerry Which Tim?
11:58 walterbender Macnamara (timclicks)
11:59 CanoeBerry McNamara
11:59 walterbender yes... more fat fingers...
11:59 I don't no how to spell :)
11:59 CanoeBerry Tim is great, no dought..
11:59 cjb that sounds good to me
12:00 CanoeBerry doubt :)
12:01 tomeu likes the idea
12:01 walterbender I guess the bottom line is that we have lots of problems we have already identified and trying to steer interest towards those would be more useful than opening up new explorations... in general...
12:01 of course, if we found the right person to explore some new idea...
12:02 CanoeBerry Anyone in touch with Jameson Quinn on useful organizational lessons learned from 2009? EG. http://wiki.sugarlabs.org/go/Category:GSoC
12:02 walterbender CanoeBerry: I have been... but have much more to ask him...
12:03 one aside re GSoC 2009: we have had some issues with being slow to reimburse the mentors for their travel expenses to the mentor's conference.
12:03 I am not sure where the bottleneck is... somewhere between Google and the SFC.
12:04 but I authorized SFC to pay them now with the expectation that the Google money will come in.
12:05 these are the monies we authorized GSoC mentors discretion over...
12:05 a few thousand $s.
12:06 Any other comments/suggestions re GSoC?
12:07 CanoeBerry Buy Tim Clicks Ice Cream
12:07 walterbender CanoeBerry: BTW, I assume not, but is OLPC applying again this year?
12:07 CanoeBerry SJ's talking about the possibility of 6 interns at OLPC this summer, but I'm not sure if GSoC would be involved at this point.
12:08 walterbender CanoeBerry: well, if any of them are going to be working in Sugar-related areas, let us know :)
12:08 dogi #link http://idea.sugarlabs.org/drup[…]soc/latest_ideas/ please write ideas there
12:09 walterbender dogi: thanks.
12:09 notes that dogi is sitting across the table from him at the moment :)
12:09 dogi :)
12:09 CanoeBerry walterbender: will do, i want a seat at the table too ;)
12:10 walterbender OK, well, as they say in CarTalk, you've wasted another hour with us... Actually, I think we got some decisions made today :)
12:11 CanoeBerry QED, thanks all for accelerated discussion this time..
12:11 walterbender Let's all agree to add our comments/suggestions to the Goals page for next time?
12:11 I think it would be good to articulate some 5-year goals too... I'll start that thread
12:12 CanoeBerry: w31-120... be there!!
12:12 CanoeBerry I would if I wasn't sick-- don't want to infect you.
12:12 walterbender It would be good to have prominent in the wiki both our short-term and long-term goals.
12:13 anything else before we adjourn?
12:14 I have a noon meeting I need to attend... so I will endmeeting now.
12:14 Thanks everyone. See you next week...
12:14 #endmeeting

Index | Today     Channels | Search | Join

Powered by ilbot/Modified.