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

#sugar-meeting, 2010-06-06

Index | Today | Next day »     Channels | Search | Join

All times shown according to UTC.

Time Nick Message
15:39 rgs_ bernie: start the meeting and then I'll go on
15:39 1) needed Journal features (will expand in a sec)
15:39 bernie so, I've dumped my personal list of critical short-term goals here: http://openetherpad.org/40QNKykhk0
15:39 rgs_ 2) visual feedback of errors
15:39 3) sharing and connectivity
15:39 silbe bernie: sure I'd like to! i'm a bit high latency, though.
15:39 bernie silbe: k
15:40 silbe some advance notice would have been fine :-P
15:40 bernie ok, I'll run through my old list so we can add/remove stuff to it
15:40 rgs_ silbe: sorry, we were at bernies house and this was kind of ad hoc
15:40 bernie silbe: we thought it would have been good to also involve others in our conversation
15:41 silbe let's add "major features" AKA collaboration rework + version support to the discussion list
15:41 ok, then I'm glad I can get involved at all - this is better than during SugarCamp :-/
15:41 rgs_ would like to see a 0.90 Journal with 1) aa's patches 2) part of silbe's work 3) a way to mount your server backups and 4) bulk operations
15:41 bernie silbe: k
15:41 rgs_: I've already taken aa's patches on
15:41 rgs_ above all.. more robustness .. and also maybe reviving cscott's old Journal2 code
15:42 (some of the code)
15:42 bernie rgs_: for (2), I'd like to see the code, but I have a strong feeling that deltas won't buy us much in terms of disk space with real-world data
15:42 silbe ok, let's add those to the list as journal / data store refinements
15:42 bernie rgs_: for (3), we need someone to work on it...
15:42 silbe and go step for step over the list
15:42 bernie 4) this is already in my list of critical goals for sugar 0.90
15:43 rgs_ http://wiki.laptop.org/go/Journal,_reloaded
15:43 bernie rgs_: maybe we could put aa on 4?
15:43 rgs_ bernie: sounds good
15:43 tch: let us know when there is some feature you'd like to tackle
15:43 bernie rgs_: is this the olpcfs thing?
15:44 rgs_: I remember reading about it some time ago
15:44 I think we should distinguish things that can realistically happen for 0.90 from those for a distant 1.0 release
15:45 I have them distinct in my slides (but I've taken off the details for a non-technical audience
15:45 so, I had these 12 points:
15:46 damn
15:46 1) Clear and complete error messages (even for crashes)
15:46   http://bugs.sugarlabs.org/ticket/1366
15:46   http://bugs.sugarlabs.org/ticket/630
15:47 this is easy... tch wanted to discuss a notification api
15:47 and associated ui
15:47 tch: what's the limitation of the current notifications?
15:47 tch bernie: theres none? the log maybe?
15:48 bernie tch: I recall seeing some function to bring up a simple message box on top of the screen below the toolbars
15:48 tch: it's used in somecases...
15:49 tch bernoe: i think it was used for shared activities notifications
15:49 bernie: ^
15:49 walterbender could be used for other notifications as well...
15:50 bernie tch: ah yes... I've also seen it in HelloMesh
15:50 walterbender but I am concerned that we don't try to get too complicated here...
15:50 bernie I think the problem #1 is that exceptions get caught and logged without providing any user feedback
15:50 walterbender I'd like to see a high bar for system notifications
15:50 bernie we could fix a few usecases easily by adding one line to the global exception handler
15:51 walterbender most crash reports are meaningless to end users
15:51 and most alerts are too.
15:51 bernie walterbender: we could hide the details, but at least we should say "something went wrong". now you get absolutely nothing
15:51 walterbender Journal is full is a reasonable exception
15:51 bernie walterbender: for example, try copying a file into a full usb stick :-)
15:52 rgs_ walterbender: what about an icon in the frame that contains the errors/alerts?
15:52 walterbender: and an hover you get to see them?
15:52 walterbender bernie: we have shell.log and I think that we should point curious users there...
15:52 rgs_ walterbender: something like a circular log buffer
15:52 tch bernie, walterbender: or for example 3G/GSM connection errors messages...
15:52 walterbender but not give them a little, unactionable info
15:52 bernie walterbender: the journal is full dialog tends to come up multiple times while some operation keeps filling it up even further ;-)
15:52 silbe walterbender: the details might be meaningless to most users, but it's very important that a) they notice something happened and b) can easily tell someone more knowledgeable what exactly happened.
15:52 tch the poor Daniel_C: has been going crazy about changing his enhancements over and over to do it
15:52 bernie silbe: +1
15:53 rgs_ likes the idea of adding an icon to the frame that would contain the important alerts/errors because adding frame icons is easy and non-invasive
15:53 bernie silbe: the usual "more details" button... we can copy what others have done
15:53 walterbender silbe: I think a report error from Log is a good idea
15:53 silbe a good first step would be to improve Garys activity-failed-to-launch stuff.
15:53 bernie silbe: +1
15:53 silbe a) it doesn't seem to trigger on all crashes
15:54 bernie silbe: I think gary's original patch already contained such improvements
15:54 rgs_ silbe: code/screenshots to the activity-failed-to-lunch stuff?
15:54 bernie alsroot: btw, we forgot to call you!
15:54 silbe b) it should give an option to easily shove the log someone useful. i.e. Journal.
15:54 bernie rgs_: it's somewhere in trac... gary did an amazing job
15:54 walterbender I don't think we want to overload Gary's design too much... Let's channel people to Log
15:54 silbe bernie: ISTR some code being left out for the release, yeah :-/
15:55 alsroot scroll back
15:55 bernie silbe: for a), I think the reason is that the approach is wrong... we don't check for the child process to die! what we do is get a notification over dbus from an exception handler somewhere in the activity class.
15:55 walterbender bernie: are we going to try to find solutions today or focus on surfacing concerns?
15:56 bernie silbe: we should really implement the startup-notification protocol to solve all these startup issues at once.
15:56 silbe walterbender: Log is too crowded currently. What we can do, though, is making Log able to interact with the Journal, so that it can open the (single-file) crash report.
15:56 bernie walterbender: good point
15:56 walterbender: so let's go over the rest of the points
15:57 2) Checks to prevent installation of incompatible activities
15:57   http://bugs.sugarlabs.org/ticket/1442
15:57 we already have code for this
15:57 silbe bernie: we should probably do both, watch the process (there's no way around that), and time out since the activity could just hang instead of dying.
15:57 bernie: how does this startup notification stuff work?
15:57 bernie it's a HUGE problem in the field... teachers try to install bundles for the wrong version of sugar from their usb sticks and schoolserver
15:58 silbe bernie: too new activities or too old ones?
15:58 bernie silbe: I think it uses X11 IPC... it's a freedesktop standard
15:58 silbe: it would work with all gnome/kde apps, without any need to "sugarize" them with silly wrappers
15:58 but let's go on...
15:58 silbe bernie: how does it solve our activity-not-starting-up-properly issue then?
15:59 ok
15:59 bernie silbe: gnome somehow gets to know when an application dies... all we have to do is copy the implementation
15:59 3) Keyboard navigability of the shell and activity toolbars
15:59   http://bugs.sugarlabs.org/ticket/1969
15:59   (gonzalo)
15:59 this is quite important, especially with broken touchpads and for accessibility
15:59 someone is working on it already
15:59 gonzalo from argentina
15:59 silbe what happened to homunqs work on keyboard accelerators?
16:00 bernie ah
16:00 forgot about him
16:00 a few people will probably reappear if we resume development and we start accepting patches in a timely fashion
16:00 silbe both homunq and dfarning are too easy to forget about :(
16:00 bernie :-))
16:01 4) Make activities work in Gnome without Sugar
16:01   CONTROVRSIAL
16:01 alsroot bernie: it could be a task for polyol
16:01 silbe BTW, fixing the code acceptance should be THE goal for 0.90
16:01 bernie this is technically easy.. .there are a couple of places in which sugar-toolkit classes choke if dbus services are not there
16:01 alsroot: polyol?
16:02 alsroot bernie: http://wiki.sugarlabs.org/go/Activity_Team/Polyol
16:02 tch bernie: personally i think all the gnome interoperability should be left (at least for now) to the background...
16:02 bernie silbe: indeed... we need old and new maintainers to take ownership of the modules which are currently stalled
16:03 alsroot bernie: it is set on C(Vala) sugar libs, it will be easier to make 4) work on polyol level
16:03 satellit_ * another needed item on Live USB sticks- "Journal full does not help: deleting from journal only fills up the overlay faster.....need back up of journal so can edit it and delete unwanted entries then rewrite
16:03 bernie tch: agreed... if someone wants to work on it good, but maybe wa have no resources
16:03 tch bernie: looking at the current deadlines and resources, we should focus to improve Sugar itself
16:03 bernie tch: we *are* working on gnome interoperability from a different PoV, btw
16:03 tch: jasg's and silbe's journal interoperability work for example
16:03 silbe if someone volunteers and comes up with nice solutions to these dependencies, we should give it a try, but I don't think we should spend too many resources on it.
16:04 bernie tch: teachers are very surprised when we say "no, you can't use activity X in gnome or application Y in sugar.
16:04 silbe: +1
16:04 silbe bernie: why the latter? what doesn't work?
16:04 it might not be pretty, but it should work.
16:04 bernie alsroot: wow polyol sounds like a huge amount of work :)
16:05 alsroot bernie: it is pretty work, Library-2 will be polyol based
16:05 bernie silbe: small things, such as sugar not supporting startup-notification :-)
16:05 alsroot ..entirely I mean, w/o any sugar-toolkit
16:05 bernie silbe: see XaoS for an example of an activty that would benefit
16:06 silbe: the Firefox activity would also be a good example. it's currently wrapped in a shim which fakes the activity startup protocol just to please sugar
16:06 alsroot: wow
16:06 silbe without having looked at it in detail, I think that making legacy applications work better in Sugar is mostly an issue of a) Sugar supporting APIs that Gnome developed in parallel to Sugar (e.g. the Frame doesn't show icons of legacy applications, while Gnome does) and b) better "window manager" support for them, e.g. a "virtual workspace" to run them on.
16:06 bernie alsroot: where's the code, out of curiosity?
16:06 alsroot bernie: http://git.sugarlabs.org/projects/polyol
16:07 walterbender I don't know which teachers you've been talking to, but this doesn't come up in the top-ten list of the teachers I speak with... their first 3 requests are stability, stability, stability
16:07 bernie silbe: (a) and (b) even more than I was thinking... for now I'd be content if the flashing icon would go away when the activity starts :-)
16:07 silbe: and maybe the ability to add gnome .desktop files to the favorites view
16:08 silbe ugh
16:08 :-P
16:08 tch walterbender: +1
16:08 silbe walterbender: I'll take that up later when we talk about whether to land major features in 0.90.
16:08 walterbender the next 3 on their lists are collaboration collaboration stability
16:08 bernie walterbender: yes, but have you talked with teachers who have been expposed to the dual gnome + sugar environments?
16:09 walterbender: indeed
16:09 so I'll skip (5) as it's the other side of the gnome interoperability thing
16:09 6) Webkit integration
16:09   (lucian)
16:10 6 is manned... I'm just unsure how fast it will become deployable
16:10 7) Faster activity startup / memory savings
16:10   (quozl?)
16:11 this point we may set aside for now... the XO 1.5 is faster and the XO-1 is probably not going to see any updates after Sugar 0.88.
16:11 alsroot bernie: in case of 7), having polyol+pygi, sugar could be pretty fast and resource consumption effective, but dunno about having them both in 0.90
16:11 bernie some think that even 0.88 is too risky
16:11 alsroot: indeed
16:11 silbe bernie: +1
16:12 bernie alsroot: I'll look into it
16:12 silbe the XO-1.5 is amazingly fast, BTW.
16:12 bernie silbe: indeed
16:12 silbe if someone could look into where we block on IO, Sugar could fly on that machine.
16:12 bernie silbe: quozl did some work
16:12 silbe: he dropped a few syncs from the logs
16:13 silbe bernie: yes, I'm already running that code, it got into 0.88.0
16:13 bernie I think quozl work should see more exposure... I'll add some of his patches to my builds to see what breaks
16:13 silbe: yeah, but there were other things too which fell through the cracks
16:13 me thinks
16:14 perhaps I'm mistaken
16:14 moving forward:
16:14 8) Integration with social networks (CONTROVERSIAL)
16:14 CanoeBerry wanted to put someone on it
16:14 silbe bernie: I'm still thinking about setting up some branch where we shove all patches that have been reviewed, but not acked yet. So bugs in new code would get noticed sooner...
16:14 -1 on that
16:15 (social network integration)
16:15 bernie PyEdu also wanted to do some work on (8)
16:15 silbe: I was thinking about doing the same
16:15 silbe: a sugar-next thing
16:15 silbe: like they do in the kernel...
16:15 silbe: what's your experience with topgit, btw?
16:15 (maybe better talk about it later)
16:16 silbe bernie: I thought of calling it -next as well, but for Linux it's all acked by the maintainers already.
16:16 ok
16:16 bernie: I rely on it. :)
16:16 bernie silbe: re social networks, this is why it's marked CONTROVERSIAL. some people like it, other hate it
16:16 silbe: if you do the -next thing you'll same me a lot of time
16:17 silbe the feature I miss most is removing dependencies (after they've be mainlined)
16:17 bernie silbe: and if you manage to keep it stable, I'll base my builds directly on it
16:17 silbe: indeed... btw, we can definitely drop GConf-dbus... I made collaboration work across 2 user accounts in linux
16:17 silbe: I'll give you the recipe
16:17 silbe bernie: social network integration might be a nice thing, but it sure is dangerous. It should be led by experienced educators, not developers.
16:18 bernie silbe: I think it should be up to deployments to decide when to enable it
16:18 silbe bernie: I'm sure it works, that wasn't the question. The hard work is foolproof documentation. :-|
16:18 alsroot thinks that such stuff could be implemented out of core at first
16:18 silbe alsroot: at the very least, yes.
16:18 bernie silbe: the integration in itself is not dangerous... if they let kids access social networks from Browse, they'll do it anyway... only less conveniently.
16:19 alsroot: indeed
16:19 alsroot: I think social networks integration could go into some activities: chat => twitter, record => flickr + youtube, etc.
16:20 silbe bernie: depending on how the integration is done, it might be more dangerous. but we're talking about things that are not even designed, so let's talk about more important stuff. :)
16:20 bernie teachers would like students to blog
16:20 and publish their works online
16:20 alsroot even has some related ideas in case of 10)
16:20 bernie silbe: yes
16:20 9) Bidirectional Journal gateway for Gnome
16:20   (torello, jasg)
16:20 silbe BTW, if I find enough time I'll work on integrating "Single-Sign-On" into Sugar.
16:20 bernie silbe: point (9) should also have your name on it
16:20 silbe: that would be useful indeed
16:21 silbe we already have a key for use in collaboration, we just need some glue code (and change key type + size) to make it seamless.
16:21 bernie silbe: if there were some framework already available in gnome it would be great
16:21 silbe people could automatically "log in" to Trac, aslo, ...
16:22 I'm afraid all the world is concentrating on the CA-focused models that there won't be an existing framework that works. :(
16:22 bernie silbe: this is a lot of work, as linux desktops in general are behind on this
16:22 silbe except maybe for monkeysphere
16:22 bernie silbe: mac os is amazingly good: kerberos + ldap + keychain + ssl certs all seamlessly integrated in the os, including the browser
16:22 silbe I don't think the Sugar side is a lot of work. it's rather the server side that worries me.
16:23 but let's talk about it sometime else
16:23 bernie silbe: ah if you use ssl certs, then it's a lot easier.
16:23 silbe: k
16:23 10) PackageKit integration (CONTROVRSIAL)
16:23    (alsroot?)
16:23 alsroot bernie: to be honest I was planing to implement ActivityLibrary activity(which will be not only activity but also something like ASLO in sugar itself, but more powerful i.e. 0install as packaging system support more hackable environment) at first i.e. out of sugar core, later ideas could be integrated to core
16:24 bernie alsroot: I'm not sure what you had in mind here.. and maybe the SoaS folks should join the conversaion...
16:24 tch alsroot: do you any documentation on that?
16:24 bernie alsroot: interesting
16:24 alsroot tch: not yet, I'm still doing low level stuff, 0sugar, polyol
16:25 tch alsroot: ok
16:26 alsroot in short terms it will be what ASLO(and .xo) lacks
16:26 but it will be rely on network access
16:26 bernie alsroot: are you planning to solve the problem with building binaries for multiple archs automatically?
16:26 silbe alsroot: OT: what's the timeline for 0sugar supporting non-Fedora systems?
16:26 alsroot bernie: yup, within 0sugar
16:26 bernie alsroot: as soon as OLPC comes out with their ARM based platform, it will become a necessity for sugar
16:27 alsroot silbe: but 0sugar doesnt require Fedora stuff, it is just 0install based tool
16:27 silbe bernie: FWIW, Sugar works fine on ARM (again - gcc and thus Xapian recently got fixed).
16:28 bernie alsroot: ah cool
16:28 walterbender cjb had gotten Sugar running on the ARM being proposed for OLPC XO 1.75, I believe...
16:28 bernie alsroot: so we only build for each arch, not for each distro? can this really work in the long term?
16:28 silbe alsroot: ISTR it not working on Debian because of naming differences. but maybe the problem was something else...
16:29 bernie walterbender: I got sugar running on the arm 2 years ago :-)
16:29 alsroot bernie: it will soft system, dependecies could be fetched from current distro (as primal way) and only fallback to custom builds
16:29 ..and only fallback to build on user side as well
16:29 silbe walterbender: I already had it running on a touch screen based ARM device a year ago ;)
16:30 bernie alsroot: olpc traditionally tried to avoid yum for system upgrades... I think this would have to change then
16:30 alsroot: one cannot do both yum and olpc-update
16:30 walterbender silbe: yes, I recall...
16:31 alsroot bernie: in 0sugar case, it will PackageKit + information about required deps in 0install infrastructure (thus users don't run yum directly, only implicit via 0install)
16:32 bernie silbe, walterbender: porting sugar itself to the arm, we all know, is very easy. the problem is finding all the activities with binary deps and rebuilding them for multiple archs.
16:32 silbe bernie: that's what 0sugar is supposed to solve
16:32 bernie which is why I've always been advocating rpm/deb packages for activities
16:32 walterbender bernie: there are actually a fairly well contained list of such activities
16:32 silbe it's the only sane long-term solution
16:33 alsroot silbe: installing deps in despite of what current env/distro is
16:33 bernie silbe: yes, only if 0sugar adds a build cluster like koji, ppa or opensuse build service
16:33 silbe alsroot: ?
16:33 bernie walterbender: the number will tend to grow with time
16:34 alsroot silbe: answer to "that's what 0sugar is supposed to solve"
16:34 bernie: 0sugar shouldn't add many custom build, anyway I'm planing to use opensuse build service
16:34 bernie alsroot: good
16:35 alsroot: I'm sure it will work well, I've already tested it some time ago
16:35 silbe bernie: except for activities with very large parts of custom code, it doesn't need a build farm, it just needs a self-hosting environment.
16:35 alsroot moreover there is python client to opensuse build service thus it could be reused from 0sugar
16:35 bernie silbe: with qemu and chroots? it's going to be very painful for activity developers who can barely compile a C program
16:36 alsroot builds his blobs in 4 chroots
16:36 tch lets move on now? :)
16:36 silbe bernie: what do you need qemu and chroot for?
16:36 bernie alsroot: but no arm?
16:36 alsroot bernie: yup, only x86/x86_64
16:36 bernie silbe: armel, mipsel...
16:36 tch: right, let's move on
16:36 11) Memory management
16:36 silbe bernie: or do you want to run x86 assembly code on ARM? that's a no-go, quite simply.
16:36 bernie    Idea: show memory icon in the frame with free memory
16:37 memory management is a big issue in sugar... kids and teachers manage to slow down their machines to death
16:37 without realizing what the problem is
16:37 silbe bernie: activities are supposed to come with full source code, so recompiling them should be easy. anything that comes with binary blobs for whatever architecture is unsupported.
16:38 walterbender bernie: we could go back to the donut :)
16:38 silbe bernie: I guess you're talking about RAM here?
16:38 bernie silbe: C source code? in the xo bundle?? (but let's postpone)
16:38 walterbender: that was a cool idea!
16:38 silbe: yep
16:38 silbe donut?
16:38 bernie silbe: the circle
16:39 silbe: it looks like a donut (home simpson's favorite food)
16:39 silbe what circle?
16:39 tch walterbender, bernie: what idea? :)
16:39 bernie *homer
16:39 tch: we wanted to show how much memory each activity was taking by making it "fill" the donut proportionally
16:40 silbe please bear with me, I haven't been around this project as long as you have ;)
16:40 bernie: how do you determine how much memory an activity takes?
16:40 walterbender silbe: that was always the problem...
16:41 the visualization was only as good as the data it was derived from, so not very good
16:41 silbe the memory model of Linux is too close to a Turing machine for my taste
16:43 bernie silbe: you need a thingie whose name I forgot
16:43 silbe: found
16:43 silbe: ps_mem.py
16:43 silbe we could give it a try and tell Rainbow to set resource limits to, say, 3/4 of RAM for every activity instance.
16:43 tch silbe: linux should great with an infinite type haha
16:43 silbe bernie: that won't help you find the RAM used by a single activity.
16:43 bernie silbe: basically, it tries to estimate memory usage by doing accurate accounting of mmaps shared by multiple processes
16:44 silbe: why not?
16:44 silbe: ah... 1 activity != 1 process
16:44 silbe bernie: and accumalates the memory usage over all processes with the same binary, e.g. all Python processes.
16:44 bernie silbe: it doesn't have to be very precise...
16:45 silbe: alternatively, we could NOT display per-activity stats, just an icon in the frame showing how much memory is "free"
16:45 silbe bernie: we should ask mstone for ideas.
16:45 bernie silbe: for some good enough def of free
16:45 silbe: NO!!! Please don't ask mstone ;)
16:45 silbe bernie: a "RAM" device showing the "free" (CLI tool) output might be a nice start, yes.
16:45 bernie silbe: you'd get the answer that takes 10 years of research to implement
16:46 silbe: all we need is a "10 lines of code" approximation which could help the user see when it's time to close something
16:46 silbe but at least in 10 years it works, instead of 20 years of constant pain due to imperfect workarounds :-P
16:47 bernie we don't need a system monitoring tool, just a graphical hint of how full your memory is getting
16:47 silbe bernie: then let's go for free output in Frame + Rainbow setting resource limits for now.
16:47 tch bernie: same with the cpu maybe?
16:47 bernie as long as the bar gets to 100% when the machine would start slowing down too much, we're good
16:48 silbe tch: CPU is even harder to analyse than memory
16:48 it might be perfectly fine that an activity is taking 100% CPU.
16:48 bernie silbe: I don't believe in the resource limits approach. it's idealistic. you don't really know how much memory an application will use because it depends on what document the user will load
16:49 silbe bernie: there are realistic limits to the amount of memory an activity can use and actually do something useful.
16:49 bernie tch: right, the cpu may also be hogged by stupid activities without the user knowing
16:49 tch: I think it's lower priority though
16:49 silbe once you get past some threshold, the machine will thrash.
16:50 tch bernie, silbe: yeah, but estimate displaying could be useful anyways, so kids understands that there is a limit...
16:50 bernie silbe: well, would you agree that we could get to a very useful memory display with very little work and later on improve this estimate with patented algorithms or even with pluggable strategies if needed?
16:50 tch in the field... they learn it in the hard way
16:50 silbe tch: +1
16:51 bernie: I always believe in the incremental improvements approach, that wasn't the question :)
16:51 that's why I said let's do the "free" output + resource limits
16:52 bernie silbe: me too :)   I think we could easily do a memory "slider" in the frame by looking simply at /proc/meminfo
16:52 silbe: ah, or with free... sure
16:52 silbe: I haden't seen that you had already proposed it
16:52 who could work on this?
16:52 tch: you?
16:52 tch bernie, silbe: i like the frame addons aproach
16:53 bernie tch: it could look like the journal full thing
16:53 silbe bernie: I'd suppose free is just parsing /proc/meminfo, so we can do the same. it's another linuxism but then parsing free would probably break on other systems as well.
16:54 bernie as a nice side effect, it would help expose our learners to some important aspects of computer architecture
16:54 silbe bernie: IMO it should be there all the time, not (dis)appear randomly
16:55 bernie I hate when computers try to abstract the user away from the physical world in which resources are limited
16:55 silbe: yes indeed in the frame all the time, alongside with battery, wifi, volume...
16:55 silbe: we could have both memory and cpu, although cpu is less useful
16:55 silbe bernie: exactly. It's the same kind of thing.
16:56 tch they could also hide and show up when some kind of level is reached,
16:56 bernie next point?
16:56 walterbender It would be cool to have all of these available as sensor inputs to Measure, Turtle Art with Sensors, etc.
16:57 silbe walterbender: interesting idea. doesn't even need any support from Sugar, you can query that from within any activity directly from the kernel. :)
16:57 let's go on
16:57 bernie walterbender: wow, yes
16:58 ok next point:
16:58 12) OS: "Panic key" to restore default settings for GNOME and Sugar
16:58 and last
16:58 this is much needed because make their systems unrecoverable very quickly from gnome
16:59 I think we could catch a key during boot to bring up a text menu with options such as "clear ~/.gconf"
16:59 well, maybe with more user-friendly explanations
16:59 silbe sounds fine. another thing I've been meaning to work on (but not found the time yet) is an "upgrade" stick that does backup + flash image + restore.
16:59 bernie silbe: this would be so useful!
16:59 silbe: now we do it with the xs, but usb would be necessary for small deployments
17:00 silbe bernie: it would be nice to keep the few (and usually safe) Sugar gconf settings when cleaning ~/.gconf
17:00 tch would be great to have Esteban Arias last flash drive back up an restore code in ;)
17:00 silbe bernie: as everything, it takes time to implement :-/
17:00 tch sorry getting out of the topic, but i had to mention that hehe
17:01 silbe the idea is easy enough: boot initrd, tar up homedir, reboot & flash, reboot into second initrd and restore homedir.
17:01 alsroot silbe: but it sounds like particular deployment workflow, not sugar itself
17:02 silbe alsroot: it's XO-1 stuff, not Sugar, yes.
17:02 bernie silbe: indeed
17:02 do we have any idea who's gonna manage the 0.90 release cycle?
17:03 I can't do it, I have the 0.88 builds until august and then I'll be sucked into other things
17:03 silbe bernie: either you or mstone I'd say
17:03 or is there anybody else we could lure into this?
17:03 bernie silbe: while mstone is one of the most experienced sugar devs, I'm a bit worried about his approach
17:04 silbe: he likes huge changes that break everything and almost never finishes the things he starts (rainbow, networking stuff, etc)
17:04 silbe bernie: then I shouldn't do it either :-P
17:04 bernie silbe: I asked michael several times to make his m_sugar tree more upstreamable, but he ignored me :-)
17:05 silbe I think there's still some personal issues at work on both sides :-/
17:05 bernie silbe: I think m_stone should be sugar's "research branch", not the "get predictable and solid releases out every 6 months"
17:05 silbe which is really a shame
17:05 bernie silbe: yes, indeed :-/
17:05 alsroot personally feel lack of plan, long time and thus short time to see new 0.90 RM
17:06 silbe bernie: which is one thing we urgently need, BTW (the research branch).
17:06 bernie silbe: btw, I'm a goof friend of michael... I really like his work and agree to many of the changes he did
17:06 silbe: I just think that such changes should be merged one at the time, after reaching consensus *AND* fixing the fallout
17:07 alsroot: I guess we cannot expect 0.90 to be out 6 months after 0.88... we should allow for some slack this time
17:07 silbe I'm not sure I agree with that given the current state of Sugar...
17:08 bernie silbe: if we make too many changes at once, breaking too many things, olpc and others will ignore our releases.
17:08 silbe: 0.88 is being looked at with suspicion because we did a few small UI fixes... some of which were requested by deployments!
17:08 silbe bernie: is there anything remaining you'd like to discuss for #12? otherwise it might be a good time to start talking about big changes for 0.90 now.
17:09 walterbender bernie: suspicion by whom?
17:09 bernie silbe: my list had only 12 points... let's talk about 0.90 as you say
17:10 silbe bernie: I was just asking whether we're finished with the last point on your list
17:10 bernie walterbender: all olpc folks I talked with told me that 0.88 is too buggy or too different from 0.84...
17:10 silbe -> fetching beverage
17:10 bernie walterbender: some of the concerns are based on misconception, but it's hard to disprove them
17:11 walterbender: dsd wants the old activty updater back...
17:12 walterbender: ed said that the new toolbar will require reprinting training materials (but they are already in 0.84 activities ;-)
17:12 walterbender bernie: there is some concern about the 0.86 toolbars... but they are such a win!!!
17:12 bernie walterbender: others said that 0.88 should come 1 year or even 2 years from now
17:13 walterbender: there's nothing we can do if our downstreams are conservative
17:13 walterbender: teachers here in paraguay were complaining because the close button was no longer hard to find!
17:13 s/teachers/trainers/
17:13 walterbender bernie: no one deployed 0.86, which is fine... I hope people deploy 0.88, but if not, we cannot stop developing/improving/maintaining
17:14 silbe FWIW, in my experience 0.88 is more stable than 0.86
17:14 walterbender silbe: I agree. And both are more stable than 0.84
17:14 if we land Tomeu's new collaboration suite for 0.90, we've presumably have more stability there as well
17:15 bernie walterbender: this was an important point in my realness talk: sugar is far from finished, we must not slow down development just because the first 1M users got used to our old design farts.
17:15 silbe walterbender: in the long run for sure. but for 0.90 it might actually increase the bug count quite a bit.
17:15 walterbender bernie: even if it were finished, it needs to evolve as the world around it changes
17:15 bernie walterbender: do you know the status of tomeu's work?
17:15 silbe bernie: +2
17:16 walterbender bernie: I don't know
17:16 bernie walterbender: yes, being conservative is typical of users with very little computing experience AND government employees... our users have both defects :-)
17:17 walterbender: the first problem may fix itself over time...
17:17 silbe it's too bad we got so few GSoC slots this yeah. automated UI testing would have made a huge difference.
17:17 bernie walterbender: there's a third issue: credibility. deployments are much more willing to deploy 0.84 because paraguay did it.
17:18 walterbender: we need deployments like paraguay
17:18 tch except for the mosquitos :)
17:19 bernie tch: trust me, the caribbeans have a lot more mosquitos
17:19 shows his legs full of bites
17:20 we gotta go
17:20 silbe ok, so what should we do for 0.90? bug fix release or major rework?
17:20 bernie endmeeting?
17:20 walterbender bernie: did you see any of the cute land crabs by the tents?
17:20 bernie silbe: if you had the time to manage 0.90, that would be great :-)
17:21 silbe land collab rework and version support, or not?
17:21 bernie walterbender: ah yes... initially we thought a crab got lost... then we figured out that they like being on the land
17:21 walterbender silbe: I think both... and the major rework may or may not land in 0.90, but we need to get that work started
17:21 silbe bernie: I sure won't :(
17:21 tch later guys,
17:21 silbe walterbender: ok, then we should land it soon. we're already rather late.
17:22 walterbender silbe: I would love to see a test branch with version control sooner than later so we can stat to understand the broader implications
17:22 silbe walterbender: that branch already exists. repo silbe, branch t/versions.
17:22 It's what I use on my XO-1 for "real" work.
17:23 walterbender silbe: I'll pull it and give it a try...
17:23 silbe it's what I base all my development on and then backport to plain 0.88/0.90
17:23 walterbender: remember to make a backup. there's no way back for now.
17:23 walterbender silbe: I would love to be able to land the write-to-journal-anytime feature in 0.90...
17:23 silbe it's planned (bernie had a nice idea that should work), but I won't have time to implement it for some time .(
17:24 walterbender: +1
17:25 BTW, I'm now using datastore-fuse to export attachments (mostly photos + PDFs for now) from my mail client (sup-mail) to the data store and manage them within the Journal.
17:25 it's a perfect combination ;)
17:26 alsroot btw pack to releases issue, having downstreams with more bigger then 6m releases, have 6m release cycle is strange for me
17:26 s/pack/back/
17:26 walterbender alsroot: we need to assess the pros and cons of the release cycle...
17:27 silbe alsroot: 6 month release cycle is fine IMO, but we can't expect them to pick up every release.
17:27 walterbender I think it is good to force a periodic coalescence of the work.
17:27 bernie catches up
17:28 walterbender: I like the 6 months release cycle even though some of our downstreams would miss it
17:29 satellit_ * do like Ubuntu with stable LTS and cutting edge?
17:29 walterbender as our downstream grows, there will be more an more skew
17:29 bernie walterbender: the purpose of 6 months is to give the project a rithm (whatever way it's spelled)
17:30 alsroot personally likes more decentralized scheme where donwstream follow regular distro way, pick up some software and bundle it to distributions
17:30 bernie satellit_: except we missed the LTS train this time :-)
17:30 silbe (rhythm)
17:30 walterbender rhythm, as in I got..
17:30 bernie alsroot: me too
17:30 walterbender: it had too many h's for me to guess it right :-)
17:30 silbe bernie: I'd rather say Ubuntu missed quite a few trains with their current LTS release :-/
17:31 bernie silbe: so we're still missing an RM for 0.90...
17:31 silbe bernie: yep. :-/
17:31 bernie silbe: not me, not you... alsroot? mtd?
17:32 silbe I don't know mtd at all, so can't say.
17:32 bernie silbe: perhaps jasg (jorge) could do it... he's a very responsible person with good judgment
17:33 silbe: he has little open source programming experience, but this is not what the RM does...
17:33 silbe: a lot of open source and technical experience would be required for maintainers
17:33 silbe alsroot: we need you as a coder, not wasting your time on procedures. (re. making you RM)
17:33 alsroot silbe: huge thank to you ;)
17:33 bernie silbe: aa and quozl also come to mind
17:34 silbe bernie: we need quozl as reviewer and coder
17:34 he's doing awesome work, BTW!
17:35 bernie silbe: and maybe as maintainer... he does already what a maintainer should do: review patches, test, propose patches, summarize important bugs...
17:35 silbe bernie: +1
17:35 bernie silbe: has anyone offered him to maintain some module?
17:35 silbe bernie: the current maintainers would need to do that I suppose.
17:37 walterbender: how about you as RM? :-P
17:38 (just kidding)
17:38 bernie silbe: I asked tomeu a few times
17:38 walterbender silbe: I guess my programming skills aren't in the critical path :)
17:38 silbe bernie: he's too unresponsive lately (not that I'm any better)
17:39 walterbender: the RM doesn't need programming skills
17:39 bernie silbe: (I'm behind on reading my mail btw)
17:39 silbe that's why I can't judge jasg, I haven't seen him do anything else
17:39 bernie I've spent some time rebasing my builds on 0.88.1 today
17:39 walterbender silbe: I was referring to you comment to alsroot :)
17:39 silbe walterbender: ah, I see.
17:40 bernie silbe: he sits next to me... rgs_ was also of the opinion that he could be a good RM
17:40 silbe: in case he doesn't do it well, we haven't lost much... it's not like there's a long line of release managers to pick from ;-)
17:40 silbe bernie: ok, if he switches from hard links to datastore-fuse, he can have the job ;)
17:41 bernie: +1 on just giving it a try
17:41 we're still far away from 1.0 anyway
17:41 bernie silbe: lol... I think that now that we have an implementation available it's a no-brainer which one works better
17:41 silbe: have you seen the 1.0 goals in my slides? they are a litttle far-fetching
17:42 silbe so even if we screw up, downstream will just skip 0.90. actually that's my goal anyway, with the version support landing. :D
17:44 bernie silbe: after saying that 0.90 should slip to give it 6 months of time, I think I have changed my mind
17:44 silbe: if we slip by a few months, we'll misalign with all linux distros.
17:44 silbe: so maybe we should aim for a very short release cycle
17:45 silbe bernie: we should release 0.90 as usual, but mention in the release notes that it might be less stable than 0.88.
17:45 let's stay aligned to the Fedora/Gnome cycle.
17:45 bernie #link http://wiki.sugarlabs.org/go/0.90/Roadmap
17:45 silbe: +1
17:46 silbe we can't align to Debian (since they're not doing time-based releases), and Ubuntu isn't caring enough about Sugar so for now Fedora makes most sense I'm afraid.
17:47 API freeze on 2010-07-19 already - that's really tight.
17:47 and we don't even have 0.90 branches open
17:48 no pylint/PEP8 fixes landed, nothing.
17:48 bernie silbe: ubuntu and fedora are almost synced, btw... so we get both for free
17:48 silbe: so the first problem is finding maintainers.
17:49 silbe bernie: and getting the current ones to retire without offending them.
17:50 bernie silbe: I think the current ones have been begging us to find new maintainers for a while
17:50 silbe: at least, they said so publicly.
17:50 silbe bernie: oh, must have missed that. :-/
17:50 nice, so we could just go ahead and ask quozl
17:52 bernie I'll ask him as soon as he gets online
17:52 shall we end the meeting?
17:53 alsroot and lets code
17:53 silbe ok
17:55 bernie alsroot: :-)
17:55 #endmeeting

Index | Today | Next day »     Channels | Search | Join

Powered by ilbot/Modified.
Webmaster