| 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.190.52.138.90> 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!458631a0fedora/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_!be348a5agateway/web/freenode/ip.190.52.138.90> 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_!~webchatdiabetes-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__!be348a5agateway/web/freenode/ip.190.52.138.90> 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 |