| 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 |