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

#sugar-meeting meeting, 2011-01-22 14:05:31

Minutes | Index | Today     Channels | Search | Join

All times shown according to UTC.

Time Nick Message
14:05 meeting Meeting started Sat Jan 22 14:05:31 2011 UTC. The chair is bernie. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:05 Useful Commands: #action #agreed #help #info #idea #link #topic #endmeeting
14:05 bernie Agenda:
14:05 * Dextrose 2 status update
14:05 * Dextrose 2 testing
14:05 * Dextrose 2 bugfixes
14:05 * Dextrose 3
14:05 * Dextrose Server
14:06 m_anish bernie, shall i roll?
14:06 bernie oops, we won't actually have the last item, because nubae is not with us
14:06 #topic Dextrose 2 status update
14:06 m_anish: sure, go ahead
14:08 m_anish okay, so the latest, greatest version of dextrose-2 was handed over to formadores+kids yesterday, it had a ton of recent fixes and a few missing things, like (1) updated activity list (2) missing 'redisable mesh after suspend' (3) auto-feedback present in build but disabled
14:09 silbe for (2) I'd suggest shipping pgf's kernel patch instead of the script hack
14:09 bernie m_anish: how many testers do we have, approximately?
14:09 m_anish need to setup a server on robbie/pyeduca servers and test auto-feedback before enabling via rpm update, other than that, most of the recent patches on @dextrose are in the build
14:09 bernie, 2-3 formadores, 20 kids
14:09 bernie silbe: agreed. it may already be in the latest olpc kernel.
14:10 m_anish: perfect.
14:10 tch bernie: can we make sure that it was included first?
14:10 bernie m_anish: when do you see them again?
14:10 m_anish the next 'release' is targeted around 31 Jan, it should be the 'polished' version of this release (if that makes sense)
14:10 alsroot m_anish: about activities list, I'll sync activities-testing.sl.o w/ activities.sl.o. so it will be recent activity versions to test
14:11 m_anish bernie, i asked this ques to roberto, he'll update me monday
14:11 tch about (3) isn't this the perfect time to gather feedback? :)
14:11 alsroot feedback just works in my case (local feedback server)
14:11 m_anish tch, exactly, as soon as i've tested the feature locally, i'll enable via update
14:12 bernie tch: I just know that it's not in the kernel we shipped with os432dx
14:13 m_anish re: testing, this is the time for us to refine our new features, we should esp be concerned about bandwidth consumption
14:13 bernie m_anish: hehe, it will be interesting to see if we can upgrade even the kernel with the yum updater.
14:13 m_anish: i don't expect it to work very well...
14:13 silbe has the rate limiting been implemented (on client side) yet?
14:14 bernie #topic Dextrose 2 testing
14:14 since we're already talking about it... :-)
14:14 m_anish atm, we're checking for updates every hour, we're potentially sending many crash reports, and every feature update requires us to update sugar-* rpm's
14:15 bernie SMParrish: are you there?
14:15 alsroot m_anish: every hour for daily updates..
14:15 bernie m_anish: do we already have the new updater?
14:15 m_anish i guess we should have separate auto-feedback.rpm and <new-feature>.rpm instead of updating sugar-*.rpm everytime
14:16 bernie, yea
14:16 i don't know how exactly it should work, but we need to minimize bandwidth consumption
14:16 silbe m_anish: do we expect to change the feedback stuff that often? (splitting out into a separate reason might make sense for other reasons, of course)
14:17 bernie m_anish: the schoolservers have squid. bandwidth will be used only once
14:17 m_anish: we could also use delta rpms, but if we limit ourselves to sugar updates, there's no need to further reduce bandwidth usage
14:18 silbe FWIW Dextrose-3 should handle that much better as it has support for "delta rpms". Not sure if we need to set up additional infrastructure to support that, but it works with the Fedora repos out of the box.
14:18 alsroot m_anish: silbe: if you are bout sending feedback, it can sends logs automatically (in customized timeout, that might be an 1h, or even a day), or manually
14:18 tch m_anish, bernie: and, at least for caacupe, there is a internal backbone between schools and pyedu office
14:19 alsroot ..though, it needs to be improved to not lose data from several sugar sessions, I missed that...
14:19 bernie tch: oh, yeah... forgot about that. then it's really no problem
14:19 m_anish alsroot, don't we check for updates hourly? that would involve using the network hourly.
14:19 bernie, tch we've 9000 machines come march
14:20 alsroot m_anish: real update happens only one time, we just check for this update hourly
14:20 ..one time in a day
14:20 bernie m_anish: no, wait. the script runs hourly, but the check happens only once per day
14:20 silbe alsroot: what do you mean with timeout? Aborting transmissing if it didn't get sent successfully within the time spam? Or sending at most one report per hour (rate limiting)?
14:21 bernie alsroot: right
14:21 alsroot: is there a random delay before the check?
14:21 m_anish bernie, alsroot, oh ok
14:21 alsroot silbe: I meant sending all reports at once (if they exist) per timeout
14:21 silbe: for automatic mode
14:22 bernie m_anish: also, the way we check for updates is by downloading the repomd.xml for one (two?) repositories. even that file could be cached by squid on the schoolserver
14:22 m_anish alsroot, bernie tch can we send a 'feedback' report when a laptop gets updated, might be useful?
14:22 alsroot bernie: about updater? it is just /etc/cron.hourly
14:22 silbe alsroot: so no rate limit yet? We should add that. If Sugar keeps on crashing (and getting restarted), bandwidth usage can get an issue (plus we'd have to filter out the spam on the server side).
14:22 bernie m_anish: that would flood us with reports! couldn't we simply check the apache logs for downloads of the updated rpms?
14:23 m_anish bernie, i was thinking of doing that only during testing
14:23 alsroot silbe: actually it sends only text logs (no any cores) in zipped file, and it needs to improved to handle several sugar sessions..
14:23 m_anish bernie, that would work as well, do the logs store different ip addresses etc, i've no idea.
14:24 silbe alsroot: even text logs can accumulate to interesting sizes
14:24 dirakx has quit IRC
14:24 alsroot silbe: if we set timeout to 1h, I not sure if kids will manage to collect 1M of zipped logs.. :)
14:24 bernie alsroot, silbe: before the servers get overwhelmed, i'm worried that *WE* won't have the bandwidth to look at the reports
14:25 speaking of which... shall we switch topic to bug triage?
14:25 m_anish bernie, yea
14:25 alsroot bernie: +1, sure we need to get it run before any tuning
14:25 bernie #topic Dextrose 2 bug triage
14:25 silbe alsroot: I guess I don't know well enough how it works... So you only send logs for one hour per day?
14:25 bernie #link http://bugs.sugarlabs.org/wiki/Dextrose
14:25 if there are important bugs that aren
14:26 m_anish bernie, browse doesn't have tabs anymore!
14:26 alsroot silbe: anyway it is just initial impl, we can/will improve even for dx-2 release time
14:26 bernie aren't showing up in this list, please tag them as "dextrose"
14:26 m_anish: oops. what happened?
14:26 silbe alsroot: sure, that's what I'm asking for. :)
14:26 bernie ; m_anish's majestic Browse with tabs!
14:26 url_50=http://people.sugarlabs.org/~anish/Browse-115.xo
14:26 i take it from here
14:26 m_anish cario got upgraded to 11000 http://wiki.sugarlabs.org/go/Dextrose/2/Todo and browse disables tabs if cairo is greater than 10800
14:27 bernie m_anish: ah, for the occasional crash on tab close? well, you can re-enable it unconditionally, because I've seen crashes even on dextrose.
14:27 m_anish: so the version of cairo did not really matter
14:27 m_anish further, not a bug, but we need to translate all the new stuff we're developing into spanish
14:28 bernie ok, who could work on translations?
14:28 tch: you?
14:28 or dirakx?
14:28 m_anish bernie, [scs] was saying he could help
14:28 silbe bernie: on my systems I haven't seen just occasional crashes, it crashes every time.
14:28 bernie problem is, we can't use pootle for this
14:28 m_anish: cool
14:28 silbe that's probably the "Browse-115 bug" on top of the to-do list, BTW.
14:28 m_anish bernie, they we're also wondering if we could have guarani, [scs] is ready to help with that as well if we've the infrastructure in place
14:29 bernie m_anish: good. he's a technical user, so you could serve him with the .po files
14:29 silbe bernie: why can't we use Pootle?
14:29 tch bernie: next week i will iterate over bug reports and patches reviews, massively fixing
14:29 bernie m_anish: adding guarani is not something we could do in 1 month. it requires changes all over the place, including glibc
14:30 silbe: because dextrose isn't in git
14:30 silbe: pootle can only checkout code from repositories, right?
14:30 m_anish bernie, oh for sure, i'm not saying we do it now
14:30 silbe bernie: then we add a git tree for translations. I doesn't need to have the exact code.
14:30 bernie tch: cool!
14:30 silbe s/tree/repo/
14:30 bernie tch: i was just going to ask this hard question: who is working on fixing bugs
14:30 ?
14:31 i think we should all participate: m_anish, alsroot, silbe, tch...
14:31 bugs are piling up in trac... and new features will generate more bugs
14:31 plus, testing in the field will uncover even more bugs
14:31 silbe bernie: let's make it easier for the translators, they're the bottleneck. Let's move our translations work where all the other translations work is happening and benefit from synergy effects.
14:32 alsroot bernie: I was targeting to 2/Todo..
14:32 bernie m_anish: it's important that you file reported bugs in trac so that developers have a single point where they can find out what's missing
14:33 tch bernie: i have been fixing/hacking some of the reports
14:33 alsroot bernie: m_anish: we need to collect bugs from bugs.sl.o that might affect dx-2..
14:33 bernie silbe: but most of the missing translations are for text in our patches!
14:33 tch: GURAIT-TO!
14:33 silbe I'll try to hang around in IRC as often as possible. If you've diagnosed a non-trivial bug and are going to work on a solution, please announce on IRC so we can agree on a solution early.
14:33 m_anish bernie, alsroot i was focusing more on dx/todo as well, + bugs reported from field
14:33 tch bernie: there is also some patch reviews from m_anish and silbe that i need to take care of
14:34 bernie alsroot: when we find an existing bug report that might affect dextrose, just add the tag "dextrose" and it will show up on http://bugs.sugarlabs.org/wiki/Dextrose
14:34 m_anish: i agree, I also prefer todo lists over bug trackers.
14:34 silbe bernie: which is why we need an additional repo for that. But it suffices to have any version of a patch there (unless the text changed) because the code doesn't matter to Pootle.
14:34 bernie m_anish: but some time ago I was forced to switch to the bug tracker because developers liked it more this way... having two different places for bugs is a no-no.
14:35 alsroot ok, lets continue to use "dextrose" keyword in bugs.ls.o, and take a look there..
14:35 silbe bernie: it doesn't even have to work. Just the strings need to be there.
14:35 bernie m_anish: the compromise might be: if it's a bug you care to see fixed, file it in trac and add a link in the todo list
14:35 m_anish bernie, alsroot +1, exactly
14:36 bernie m_anish: the other testers (tabs, satellit_, etc.) will certainly file bugs in the tracker...
14:36 m_anish bernie, field reported bugs and our todo should be higher priority w.r.t rolling out stable releases
14:36 bernie, makes sense
14:37 silbe m_anish: in general yes. But we shouldn't forget that "the field" is affected by all bugs and might just not figured out it's a bug or haven't reported it.
14:37 bernie m_anish: you can tweak priorities yourself and beg people on irc to fix them
14:38 m_anish: you're basically now working as a Product Manager for Dextrose, because you're closer to our customers
14:38 m_anish silbe, agree, we need to go through trac and figure out high priority tasks every once in a while
14:38 bernie m_anish: so you know better than the rest of us what's important to them
14:38 tch bernie: +1
14:38 bernie silbe, alsroot, tch what pateches still need to be merged?
14:39 silbe, alsroot, tch: at this time, we should start to think of dx2 as frozen for new features. we have only one month of testing left.
14:39 tch bernie: hard to say, we need to define a mechanism so we know the patch is already in.. maybe a reply to the ml patch thread?
14:40 silbe for Dx-2? It'd probably make sense for someone to go through recent upstream commits and my outstanding patches to check if anything is of value resp. has been updated.
14:40 bernie m_anish: users and pyedu folks might also come up with random new feature requests now that they're seeing the new release. please, resist  the temptation to do it in dx2... put their requests in the todo list for dx3 instead, even if it seems easy stuff.
14:40 alsroot is waiting of m_anish or tch (ie someone who are close to the field) go though bugs.sl.o and mark them as "dextrose"..
14:41 bernie tch: i usually keep the email unread if i think i have to be the reviewer
14:41 silbe tch: yes, that would be good during the DX-2 and DX-3 overlap. Later we can just use Patchwork.
14:41 m_anish silbe, +1, i'll upstream a few pending commits today that went into the build yesterday
14:41 tch bernie: the problem is review != applied
14:41 bernie tch, alsroot: whoever posted the patches can ping them if they have not been reviewed or merged yet
14:41 dfarning bernie, +1 to resisting feature creep.
14:41 bernie tch: indeed.
14:42 m_anish tch, alsroot bernie silbe is it okay for everyone to check against the commit log for dx-2?
14:42 bernie tch: we all have commit access, don't we?
14:42 tch m_anish: sure,
14:42 m_anish: for now
14:42 m_anish bernie, okay, point taken
14:42 silbe m_anish: sorry, context?
14:42 alsroot bernie: you mean to dextrose@ (m_anish should take care of them, as a dx-2 maint), if you are for upstream, imho, we need to focus on dx-2 release and push/see  all pending patches to upatrema after that
14:42 bernie so, i think the chaos is caused by the fact that we don't have a patch monkey for dx2 presently
14:43 for dx1, i was doing this in addition to running builds
14:43 for dx3, silbe is doing it
14:43 who would like to be the patch monkey for dx2?
14:43 m_anish silbe, i was thinking of upstreaming all pending commits today and telling ppl to check against the commit log if everything they sent to the list went mainline
14:43 alsroot oops, stop, "we all have commit access",
14:44 *stop*, I guess would be useful to have only m_anish dx-2 maint (and commiter), otherwise we will lose ourselves..
14:44 bernie alsroot: yeah, but after writing that i realized that it creates some sort of anarchy that doesn't work very well
14:44 alsroot: agree with you
14:44 ok, shale
14:45 ok, shall we send patches with "To: anish" from now on?
14:45 alsroot imho, jsut to dextrose@, m_anish needs to track them all..
14:45 bernie m_anish: would you have the time to go over the dextrose ml and hunt for any pending patch that you may want to merge
14:45 ?
14:45 m_anish alsroot, bernie it would be easy for me to track if i upstreamed all dx-2 work
14:45 bernie alsroot: it's customary in the linux kernel ml to have "To: <maintainer>" and "Cc: <list>, <others who may care>"
14:46 alsroot: so the maintainer cannot say "i hadn't seen the patch" :-)
14:46 m_anish bernie, alsroot i can go over, but i'm requesting that ppl go over the commit log just this once (when I upstream pending commits)
14:46 bernie m_anish: ok.
14:47 tch m_anish: we should use another word for upstream while we are here,
14:47 silbe m_anish: when you say upstreaming, do you mean posting to sugar-devel for inclusion in sugar* mainline?
14:47 bernie anyone who cannot find their patches in git, please resend them to anish (and to the list)
14:47 m_anish tch, s/upstream/dx\/mainline/
14:47 tch m_anish: :)
14:47 m_anish silbe, ^
14:47 bernie m_anish: it's customary to *always* reply to patches, even if you reject them (with an explanation, of course!)
14:47 silbe ok, that slowly clears up some confusion for me
14:47 alsroot m_anish: I'll go through dx commits as well, to see its correspondence w/ dextrose@ (if you meant that)
14:48 bernie alsroot: +1
14:48 silbe bernie: not for all subsystems (e.g. wireless), but I agree it should be.
14:48 alsroot m_anish: but you need to share build patches (ie commit them)
14:48 m_anish alsroot, i'll do that today
14:49 alsroot is subscribed to commits to dextrose, will catch them..
14:51 silbe For DX-3 we can set up a git hook to update Patchwork status and send out an automatic email response (Patchwork has the Message-ID that we need for the reply).
14:52 bernie silbe: nice
14:53 silbe: whatever seems to work best for you
14:53 silbe bernie: whatever takes the least of our time for monkey tasks :)
14:54 bernie: #topic ?
14:54 bernie #topic Dextrose 3
14:54 silbe thx
14:54 bernie :-)
14:55 silbe: haha, you're lucky to be a "patch monkey". that's a good job in kernel land. you could be a "kernel janitor" or even a "patch whore".
14:56 silbe I've finished the first few patch sets for DX-3. There are still a number of "legacy" patches in it (accessibility series, backup, a few others); I'll work out those as I get around to resp. get hooked up with the authors.
14:57 SMParrish is working on the build side. Sugar doesn't start yet, we still need to figure out why. We should send him a serial cable. ;)
14:57 bernie silbe: debugging olpc-dm is a pita
14:57 silbe: i usually do startx with an xterm, then run olpc-session in it
14:58 silbe bernie: I learned a lot about git. It's really awesome for this kind of task once you get the hang of it. :)
14:58 bernie: Too bad nodm doesn't have an active upstream either. :(
14:58 bernie silbe: you should teach me as well!
14:59 silbe: what's nodm?
14:59 silbe: yet another dm?
14:59 silbe bernie: we should do some "side-by-side hacking" from time to time. But I should better get back on topic...
15:00 bernie silbe: at next Sugar Camp
15:00 silbe bernie: like olpc-dm (or slim?), but working more like a regular DM => better compatibility with CK & co.
15:00 tch bernie: sugar camp ftw
15:01 bernie silbe: yeah it would be good to switch to something sensible, but it's probably olpc's call
15:01 silbe I'm currently trying to convince Simon (OLPC) to base their upcoming F14 builds on Sugar 0.92 instead of Sugar 0.90.
15:01 bernie silbe: we have an arm builder, but it blows. very little memory, very little disk space.
15:01 silbe What I actually upstream in the next few weeks depends on the outcome of these negotations.
15:02 bernie silbe: good point
15:02 silbe: olpc really picks sugar releases too late
15:02 silbe If OLPC is not going to ship version support, would we want to do so in Dextrose-3?
15:02 bernie silbe: tell simon that he'll have an easier time merging patches upstream if he picks 0.92
15:03 silbe bernie: already done, but he's still reluctant.
15:03 bernie silbe: which version support?
15:03 silbe bernie: mine ;)
15:03 SMParrish silbe: why is he reluctant?   btw good morning all
15:03 bernie silbe: what's his argument?
15:03 silbe bernie: (Journal object versioning)
15:03 bernie silbe: ah, in the journal
15:04 silbe: can you post the patch for review? (maybe both on sugar-devel and dextrose)
15:04 silbe The argument is that Sugar 0.90 is buggy enough and they don't need any more bugs from 0.92.
15:05 bernie silbe: i do agree in having versions in the journal, but not deltas. i don't believe they are really going to save enough space on real journals to justify the added complexity & fragility.
15:05 silbe bernie: I haven't prepared the new one yet. Whether I do so soon (or concentrate on other stuff like bug fixes) depends on whether DX-3 is going to include it.
15:05 bernie: you haven't even looked at my version support branch, have you? :-P
15:05 bernie silbe: which new bugs did we introduce in 0.92? very little was merged in this timeframe.
15:05 silbe (not that anyone ever has)
15:06 bernie silbe: nope, i haven't looked... i admit it.
15:07 silbe: if it works well, versions support might be a killer feature in dextrose 3
15:07 silbe bernie: Just to be sure I checked again yesterday: There are only two changes that are not bug fixes or small changes requested by deployments: Simons dotted versions patch (already shipped by OLPC in production builds I believe) and my style cleanups.
15:07 bernie silbe: well, perhaps you could write an email with this research to simon and langhoff
15:08 silbe There were one or two bugs introduced by my cleanups that I already fixed. I don't expect many more to be found. So for all practical purposes Sugar 0.92 is much better than 0.90.
15:08 bernie: I already did, at least to Simon.
15:09 Waiting for him to reply on monday (he seems to take the weekends off ;) ).
15:09 I also offered not to upstream version support or any of the pending patches if they're afraid of them.
15:10 bernie silbe: it might be langhoff who makes the decision, in the end
15:10 silbe ok, good to know.
15:11 I do hope they hire someone to work on all the Collaboration bugs, not matter if they choose 0.90 or 0.92.
15:11 bernie tomeu would still be available, i think
15:12 they could hire collabora and they would make him do it
15:12 silbe that's fine with me as long as the bugs do get fixed. As-is, 0.90/0.92 is too buggy to use.
15:13 (at least from a testers Pov)
15:13 ok, I guess we should move on to the next topic.
15:14 bernie there's no next topic :)
15:14 i guess we could wrap up?
15:14 good meeting everyone
15:15 tch :)
15:15 bernie tch: yo-kat-ta
15:15 tch hahaa
15:15 m_anish :)
15:15 tch bernie: e
15:15 bernie: #endmeeting?
15:15 bernie #endmeeting
15:15 meeting Meeting ended Sat Jan 22 15:15:53 2011 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot. (v 0.1.4)
15:15 Minutes: http://meeting.sugarlabs.org/s[…]-22T14:05:31.html
15:15 Log:     http://meeting.sugarlabs.org/s[…]11-01-22T14:05:31

Minutes | Index | Today     Channels | Search | Join

Powered by ilbot/Modified.