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

#sugar-meeting meeting, 2010-12-11 14:01:59

Minutes | Index | Today     Channels | Search | Join

All times shown according to UTC.

Time Nick Message
14:01 meeting Meeting started Sat Dec 11 14:01:59 2010 UTC. The chair is dfarning. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01 Useful Commands: #action #agreed #help #info #idea #link #topic #endmeeting
14:02 arjs dfarning: hi David, very useful, thanks a lot for sharing your thoughts.
14:02 dfarning arjs, great if you have time should we skype after the meeting.
14:02 tch <tch!be348a5a@gateway/web/freenode/ip.> has joined #sugar-meeting
14:02 silbe dfarning: can you send a PDF of the chart? I don't have dia installed on any of my systems currently.
14:02 tch hello everyone
14:02 arjs btw, anish might be busy with last minute packing/preparation so might not be able to attend...hes leaving for the airport in a few hours
14:02 silbe (but I'll just install it if it takes you too long to produce a PDF)
14:03 arjs also would like a pdf of the chart
14:03 (if easily possible)
14:03 dfarning silbe sure. can you start doing weekly summaries with every one while I create the pdf?
14:03 SMParrish_mobile <SMParrish_mobile!458631a0@fedora/SMParrish> has joined #sugar-meeting
14:04 silbe dfarning: ok
14:04 arjs dfarning: i look forward to talking over skype, however id need bit more time to compile my thoughts on your response..perhaps by tomorrow
14:04 tch_ <tch_!be348a5a@gateway/web/freenode/ip.> has joined #sugar-meeting
14:04 dfarning arjs, sure.
14:04 tch_ back,
14:06 silbe tch_: ok, then let's start with you. I haven't seen alsroot yet.
14:06 alsroot hi all
14:06 silbe ah, ok, then alsroot first :)
14:07 tch has quit IRC
14:07 alsroot keeps his TODO on http://wiki.sugarlabs.org/go/U[…]#Foreground_tasks
14:07 tch_ tch_: kk
14:09 silbe alsroot: did anything interesting happen this week?
14:10 dfarning ok I sent the pdf.... I will work on the scale for next time.... this one took up 4 pages for eight people:(
14:10 alsroot silbe: nope, interesting is being planned for a bit later :) http://wiki.sugarlabs.org/go/P[…]form_Team/Roadmap
14:11 silbe alsroot: BTW, is there a reason we'd want to support both formats in the updater? Isn't a.sl.o the only thing that supports the non-wiki format? Does it have some kind of advantage over the microformat?
14:12 dfarning smParrish, SMParrish_mobile, tch_ I talked to alsroot last week and he mentioned that he would appreciate more feedback on bug priorities.
14:13 alsroot silbe: I guess everything needs to be done on purpose, as a sugar doer, I'd prefer regualr ASLO updater (ie update to recent versions all my activities), for sugar deployments, microformat makes sense (batch updater)
14:14 SMParrish_mobile alsroot: I agree with you on that
14:14 silbe alsroot: so the updater does different things for different formats? Ouch.
14:14 but we can talk about that later :)
14:15 alsroot silbe: I mean that deployments need batch updater and regular ASLO updater can't help here, but microformat can
14:16 anyway /me refers talking in terms of purposes, ie, not talking about particular impl(microformat, etc) but about "batch updater"
14:16 silbe alsroot: the question is why "single" users would want to use the other format. Ideally the microformat should be able to handle both use cases. It's just a format.
14:17 hmm, looks I should install dia anyway. The labels are cut in half, it's virtually unreadable... :-/
14:18 tch_: can you report on your progress in the mean time?
14:18 tch_ silbe: sure,
14:18 silbe BTW, I really like garycmartin's new mockups.
14:18 alsroot silbe: aslo updater already works, we just need to mixin "batch" functionality, how it will be done is not so important (but m_anish_afk already implemented initial version)
14:19 ..basing on microformat
14:19 dfarning silbe, yes... I can't figure out how to scale the pdf correctly:(
14:20 SMParrish_mobile IMO a.s.l.o updater should be installed on all builds and then the batch updater for the custom builds for deployments with their activity list
14:21 tch_ silbe: well, last week i finished the messages notification implementation based on the first gary mockups (becasue they were the only i had) for dextrose, then started riviewing the tickets which requires it, in example #630, So i just followed Eben's comment to do  quick patch and see people reactions on list
14:22 alsroot SMParrish_mobile: what is I'm thinking about, batch updater doens't make much sense for upstream, it is useful only for downstreams
14:22 SMParrish_mobile agrees
14:22 alsroot jsut not sure, should we have two icons in CP
14:23 walterbender_ <walterbender_!~webchat@diabetes-3.media.mit.edu> has joined #sugar-meeting
14:23 tch_ alsroot: we should hide the one that is not being used in that case
14:23 SMParrish_mobile have to give that some thought
14:23 dfarning alsroot, would it me easy to consider the two updaters as extesions and make one of the other visable depending on which is needed?
14:24 one of the keys to projects like drupal is the ability to extend it to meet specific users needs.
14:24 silbe dfarning: Try "Page Setup". I got a fixed PDF, but my MTA is acting oddly. Will need to take a look at it later.
14:24 tch_ alsroot: otherwise it would create confusion,
14:24 dfarning ^^s/me/be/
14:24 alsroot dfarning: it will be easy, eg, gconf key
14:26 SMParrish_mobile batch updater should only be on deployment specific versions.  normal updater for generic releases
14:26 dfarning alsroot, +1 the notion of extendability, via drivers, is also what makes the kernel so successful!
14:26 silbe alsroot: I don't think we should have have two updater or two updater icons. We should make a single updater with a single set of settings that works for both use cases. Ideally in parallel, but if necessary with a single option to switch between the two behaviours.
14:27 tch_ silbe: not sure if its an abuse of gconf again, but the format could be set there,
14:28 silbe I'd prefer to let the user configure several sources in the Control Panel, each with a set of options (e.g. take the very latest version or only "vetted" ones)
14:28 tch_ silbe: because is something it  won't change, and is it setup when deployments generates the build
14:29 alsroot we can patch exited updater to add microformat batch feature, and enable it in run time (but maybe disable by default) via regular check boxes (eg)
14:29 silbe we would, however, back it with gconf so deployments can pre-configure it easily (as with all other Sugar settings)
14:30 SMParrish_mobile silbe: +1
14:30 silbe alsroot: is there a reason you mix "microformat" and "batch feature"? Couldn't we support just the microformat and make the updater support both "batch" and "non-batch" operation?
14:30 tch_ silbe: well, i am not so sure about letting users to modify such things, and the reason is that.. having too many different versions of acitivties in a huge headache in class, for the teachers.
14:30 dfarning silbe, the deployment will want to configure which updater is available.   In large deployments there are advantage in having everyone run the same version of activites.  For example it makes it easier to 'work around' know bugs.
14:32 silbe dfarning: I'm not sure deactivating the "non-batch" update feature is the right way to tackle that issue, but I'm neither a UI designer nor a teacher.
14:32 alsroot silbe: as I said particualr impl is not so important, I guess, it will just up to the dev who will implement it
14:32 is just curious, do we need to have one ASLO collection for batch updating per deployment or let user select collections (/me prefers simplicity, ie, one collection)
14:33 silbe from upstream perspective, I'd want it to be as unified as possible, to reduce the chance of bugs in either mode.
14:33 tch_ silbe: the main reason to have this microformat is actually letting the deployments to control the activities versions
14:33 silbe and as a user, I would want easy updates of "extra" activities I have installed
14:34 alsroot silbe: I think would be better to work from purposes basis, if we will tallk about unified way, we never finish it
14:34 dfarning alsroot, as a general rule, deployments will want to preselect a set of default activities and versions.
14:34 silbe tch_: I understood that. What I don't understand is why we need to keep supporting the other format.
14:34 walterbender_ tch_: if the updater is based on the deployment-selected collection (and no collection selected would imply just give me the latest) and the user could update individual activities from Browse, why doesn't stat cover all the cases?
14:34 alsroot moreover /me is working on another way, 0install :)
14:35 tch_ silbe: unification is good, i am just pointing out that it should not be configurable from the GUI, because that will cause having students with too many different versons of activities some times, and it is considered a problem in deployments
14:35 silbe walterbender_: it covers all cases, but is a PITA. That's the reason we have package managers and distributions.
14:35 alsroot dfarning: so, one collection (w/ versionsed activiites), eg, Dextrose-for-... ?
14:36 walterbender_ silbe: I don't see how anything that is being proposed makes it less of a PITA, at least for our end users
14:36 dfarning silbe, the current reality is that deployments don't use aslo because it breaks too much stuff to have unknow versions.
14:36 alsroot silbe: btw, what we are taling about is exactly the purpose of "Doest environment", I'm hopping to have initial verison of it w/ 0.92 release
14:36 silbe tch_: gconf has support for "mandatory" settings. The deployment source would simply be the first one and override all others.
14:36 alsroot *Doer environment
14:37 silbe walterbender_: AIUI the updater automatically updates all installed activities. You need to invoke only the updater (or maybe it even does a background check itself?), not check each activity on a.sl.o individually for potentially available updates.
14:39 dfarning alsroot, silbe lets wait for feed back from anish and roberto before making a final decision.  So for now two updaters with two icons.  We can then hide one based on their feed back.
14:39 walterbender_ silbe: as it should be for the normal user... but the kid who wants to be on the edge for, say, Turtle Art, she can override the default by going to ASLO
14:40 alsroot dfarning: the 3rd option is having one updater w/ regular behaviour and batch mode (maybe defualt for deployments)
14:40 silbe dfarning: but that's because the current choices are either a) don't use a.sl.o or b) always get the latest version, right? In the future, they'd have choice c) get vetted version from a.sl.o for all activities they explicitly included in the set (and leave the decision for activities not in the set to the user).
14:41 tch_ the idea is to get the activities that teachers require in very few clicks ;) if the kids upgrade teachers can just ask them to delete and run the updater, problem solved.
14:42 silbe walterbender_: that's independent of the updater. I don't think we'd want to prevent users from explicitly installing other activity versions.
14:43 dfarning lets set this aside.... I'll draft a use case document this week and we can look at it next saturday.
14:43 silbe but I'd say we move on to notifications, we already spent much more time on the updater than I intended.
14:43 +1
14:44 tch_ kk,
14:46 i as mentioned a bunch of lines before, i already have a working  implementation of earlier desings, it is very simple, supports access from shell and from dbus and it only display messages :P
14:47 alsroot though we already landed tch_'s notification code
14:47 tch_ so, based on that, i started reviwing tickets and other possible use cases.. #630 is probably a good example, so i started by that following eben's comments
14:48 alsroot: it is not yet on our builds i think
14:48 alsroot ..to dextrose branch
14:49 tch_ alsroot: it should be soon, i hope..
14:49 SMParrish_mobile has quit IRC
14:50 dfarning silbe, how about your week?
14:50 silbe tch_: so you won't work on a v2 that implements the more recent mockups?
14:52 dfarning: I got mostly bogged down by non-AC work I'm afraid. I've continued discussion with Simon today; we'll announce results on sugar-devel ASAP. It's a compromise, so don't expect anything great, but it'll allow us to unblock the queue.
14:53 tch__ <tch__!be348a5a@gateway/web/freenode/ip.> has joined #sugar-meeting
14:53 tch__ connection lost~
14:53 where were we?
14:53 dfarning silbe, +1 the key is unblocking the queue.... we can optimize later.
14:53 tch_ has quit IRC
14:53 tch__ can someone share the back log from the last i said? :)
14:53 silbe dfarning: minor stuff includes one of my Patchwork patches getting accepted upstream (for the second one I was asked to provide test cases for the test suite and possibly make some enhancements).
14:54 15:51 < dfarning> silbe, how about your week?
14:54 15:51 < silbe> tch_: so you won't work on a v2 that implements the more recent mockups?
14:54 15:53 < silbe> dfarning: I got mostly bogged down by non-AC work I'm afraid. I've continued discussion with  Simon today; we'll announce results on sugar-devel ASAP. It's a compromise, so don't expect  anything great, but it'll allow us to unblock the queue.
14:55 tch__ silbe: i like the desing but i am still thinking about it, i will state my digested opions on the mailing list :)
14:56 dfarning silbe, +1 the answer from Richard about battery charge was very complete.  That is great.  That is great because it means that richard who is very busy is 'investing' the time to answer you questions!
14:56 tch +1
14:56 silbe so we should postpone the branch decision for another week.
14:57 ?
14:57 SMParrish, are you around or did we lose you?
14:57 silbe dfarning: when I first wrote the patches, we chatted almost a full day on IRC. I learned _loads_ of stuff about batteries and the XO EC. OLPC is a pretty unique vendor in that regard.
14:58 dfarning silbe, great.
14:58 silbe dfarning: yep, I think we should. Not much longer than a week, though. Either SL will move on or we will.
14:59 dfarning silbe, sound goods.  arjs and I will start providing more information about the business model and goals over the next couple of weeks.
15:00 pablo is at a ceibal jam event today so he could not make it.
15:00 silbe I just hope dwmw2, pgf and MitchBradley can agree on where to put the information soon so I can send another version of the patch and get it accepted upstream.
15:00 tch__ to bad, ;/
15:01 dfarning bernie is still recovering from his last couple deployments.
15:01 does anyone have any questions or concerns we should looks at?
15:02 silbe dfarning: looking forward to it. Your diagram was pretty "terse". Just to make sure we're all on the same line: All Dextrose 3 patches for sugar* will go through me and I'll commit updated patch sets to the dextrose repo so SMParrish can build images with the latest changes?
15:02 tch__ silbe:  questions about dx3
15:03 silbe BTW, SMParrish: is the target still 14.01.2011 or do you need a Sugar 0.90 earlier now?
15:03 tch__ silbe:  have we defined wich dx1-2 feature are going to land on 3?
15:03 silbe: custom features
15:04 dfarning silbe, +1 it was intentionally terse.  It provides the overall map.... but you guys as implementers have the best understanding of the actually implementation.
15:04 tch__ silbe, SMParrish: we should discuss about what i just said :)
15:05 silbe tch__: I don't think we have yet, but we should. Do we have a customer for DX3 already? I.e. can we wait until I prepared the first patch set or should we start setting targets now?
15:05 tch__ silbe: custom feature are things we can port forwars later, so yeah we can wait for doing it
15:05 dfarning silbe, Initial I thought that SMParrish as pm would control the patch flow.... but over the last couple of weeks you have shown that you can 'get things' done with both dextrose and upstream.
15:07 tch__, silbe can you continue this after?  we are at an hour and we need to keep these meeting moving.
15:07 tch__ silbe:  I just want to make sure dextrose keeps its meaning :)
15:08 of course,
15:09 dfarning ok let's wrap this up.  I'll try to do a summary today so we can continue the discussions as needed.  but my nephew is keeping me busy:)
15:09 #endmeeting.
15:09 meeting Meeting ended Sat Dec 11 15:09:37 2010 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot. (v 0.1.4)
15:09 Minutes: http://meeting.sugarlabs.org/s[…]-11T14:01:59.html
15:09 Log:     http://meeting.sugarlabs.org/s[…]10-12-11T14:01:59

Minutes | Index | Today     Channels | Search | Join

Powered by ilbot/Modified.