| Time | Nick | Message |
|---|---|---|
| 09:19 | alsroot | erikos: rethinking fructose |
| 09:19 | erikos | alsroot: yup yup |
| 09:19 | tomeu | agenda: 0.88: release process changes, new features, what else? |
| 09:20 | agenda: maintenance of the 0.84 branch | |
| 09:20 | erikos | agenda: rethinking fructose |
| 09:20 | tomeu | agenda: adding 3g support to sugar, the field needs it in 0.84 at the short term |
| 09:21 | agenda: definition of glucose and sucrose | |
| 09:21 | anything else? | |
| 09:21 | erikos | agenda: maintenance |
| 09:21 | tomeu | oh, true |
| 09:22 | erikos | tomeu: what do we do without wiki? |
| 09:22 | tomeu | erikos: we update it afterwards? |
| 09:22 | or we need it for anything else right now? | |
| 09:22 | erikos | tomeu: yeah, i mean more as a base to discuss things |
| 09:23 | tomeu: I guess I can work around it for the 0.88 items | |
| 09:23 | tomeu | erikos: we'll have to try to remember what it's there :/ |
| 09:23 | erikos | tomeu: shall I start? |
| 09:23 | tomeu | erikos: sure |
| 09:24 | erikos | 0.88 - roadmap |
| 09:24 | I have updated our roadmap and added a few more deadlines | |
| 09:24 | basically i mirror the gnome one | |
| 09:24 | http://live.gnome.org/TwoPointTwentynine/ | |
| 09:25 | a) we have an UI freeze now | |
| 09:25 | b) feature freeze is earlier then before | |
| 09:25 | c) earlier API freeze | |
| 09:26 | I hope this will help us to get a much more stable platorm. | |
| 09:26 | tarball due days are mondays | |
| 09:26 | and release days are wednesdays | |
| 09:27 | I hope that by the weekend the release is then packaged | |
| 09:27 | ---> testing teams | |
| 09:27 | i outlined the 0.90, too | |
| 09:28 | so people with features missing the train for 0.88, know when they can land the feature next | |
| 09:28 | tomeu | how much helps us the UI freeze? |
| 09:28 | erikos | and - it allows for more long term planning |
| 09:28 | tomeu: the UI is a crutial part | |
| 09:29 | tomeu | the UI or the UI freeze? |
| 09:29 | erikos | tomeu: I would like to see changes to it thought out well |
| 09:29 | tomeu | oh, ok |
| 09:29 | erikos | and, it helps for documentation |
| 09:29 | and release notes etc | |
| 09:30 | as well, the translation team (context) | |
| 09:30 | tomeu | the problem with the freezes in general is that not by stopping doing something earlier you will get more quality. it also requires that the right people do the right stuff at the right time |
| 09:30 | erikos | tomeu: in general: the freezes seems early now, but the 6 months cycle stays that way (long term) |
| 09:30 | tomeu | for example, if we have a long code freeze period but people don't fix bugs because are already working on new features for the next reelase or just doing any other stuff, we don't really get a more stable release |
| 09:30 | erikos | tomeu: sure |
| 09:31 | tomeu: the thing is, with a more structured cycle I hope to give a better framework for the work | |
| 09:31 | tomeu | similarly, the UI freeze is less useful for sugar than for gnome because we don't have a documentation team aiming to release updated docs along with the new release |
| 09:32 | erikos: I agree with that being necessary, but worry about not being enough | |
| 09:32 | so we get to pay but get nothing in return | |
| 09:32 | erikos | tomeu: for example, I know I have API work to hand in at date X |
| 09:32 | tomeu: and will do that work first | |
| 09:32 | tomeu: what are your suggestions to help enforce that? | |
| 09:33 | tomeu: from my side: I want to be louder about the dates | |
| 09:33 | tomeu: sending more reminders etc | |
| 09:33 | tomeu | I don't think that's anything that can be enforced |
| 09:33 | erikos | tomeu: give myself a good example ;p |
| 09:33 | tomeu | giving more visibility is a good step |
| 09:34 | erikos: I mean that maybe there isn't so much value for us in adding more strict freezes | |
| 09:34 | that we should be a bit more flexible | |
| 09:35 | about the UI freeze, if we get people from the design team to give opinions, it will be great (I think we'll get that) | |
| 09:35 | it will be harder to get opinions from the deployments | |
| 09:35 | that I think should be also involved in the user experience | |
| 09:36 | erikos | tomeu: well, I think setting the freeze dates is mainly a developer decision |
| 09:36 | tomeu: as we are there to guarentee a stable software | |
| 09:36 | tomeu: for design team for example, only one date matters | |
| 09:37 | tomeu: the UI freeze one | |
| 09:37 | tomeu | hmm, but can developers guarantee a UI that improves at every release? |
| 09:37 | erikos | tomeu: and peobably the feature freeze one |
| 09:37 | tomeu | or can developers guarantee complete translations or useful and updated documentation? |
| 09:38 | erikos | tomeu: no each team must fullfill their task of course |
| 09:38 | tomeu | so the core of what I'm saying is that freeze dates should be defined based on what we can expect from each team |
| 09:38 | though I see value in establishing a framework for decisions to be taken at the right times | |
| 09:39 | dsd_ | many deployments would be extremely happy about a UI that changes less or less frequently |
| 09:39 | since all training materials need to be re-done each time, and in some cases more training sessions need to be given | |
| 09:40 | tomeu | dsd_: the problem is that I guess we would prefer to stabilize on an UI that is better, rather than stabilize on what we have now and live with it forever |
| 09:40 | but we can get quickly to a stable UI if we don't mobilize the whole, broad sugar community | |
| 09:40 | (deployments) | |
| 09:40 | erikos | tomeu: ok, of course each team should have the best environment on working |
| 09:41 | dsd_ | i think you'll always have ideas for how to make the UI better |
| 09:41 | erikos | tomeu: any concrete changes to the roadmap, where you see we could improve? |
| 09:41 | tomeu | dsd_: yeah, but not all of them have the same value |
| 09:41 | dsd_ | are there major changes planned for 0.88? |
| 09:42 | erikos | dsd_: we are still in brainstorming phase |
| 09:43 | tomeu | erikos: sounds good to me |
| 09:43 | erikos | tomeu: what sounds good to you? |
| 09:43 | tomeu | dsd_: and we cannot really decide for the deployments how much value has every change |
| 09:43 | erikos: the gnome roadmap | |
| 09:44 | dsd_: to date, teachers have told us where are problems, but I think we also need their involvement in the rest of the process | |
| 09:46 | erikos | tomeu: maybe the UI freeze could be put to the 22 of February |
| 09:46 | tomeu: if you think that would give us more chances to land things | |
| 09:46 | dsd_ | understood |
| 09:46 | also i guess UI freeze is different from having to redo training materials | |
| 09:47 | because it depends how much the UI changes, really | |
| 09:47 | erikos | dsd_: yeah, I think so |
| 09:47 | dsd_ | mind you, even smallish changes before have been painful... for example the deployments that rejected the 7.1 --> 8.1 upgrade |
| 09:47 | its not like things changed too much there | |
| 09:47 | always difficult! | |
| 09:48 | erikos | yeah, havig users is a pain and great at the same time :/ |
| 09:48 | dsd_: I think, once we have reached 1.0, users can stay with that for longer | |
| 09:48 | dsd_: years even | |
| 09:49 | dsd_: before they migrate to 2.0 | |
| 09:51 | so, are people mainly happy with the roadmap? | |
| 09:51 | alsroot | +1 |
| 09:51 | erikos | one thing that is not present in the gnome one, is our "Feature Acceptance" date |
| 09:51 | this is for the Feature process and is at mid january, if i recall correctly | |
| 09:54 | wonders if we should put a flag on the Feature description page about "UI changes involved" | |
| 09:54 | so we can get attention from the design team | |
| 09:54 | early | |
| 09:54 | tomeu: we need to reask gary if he would lead the team | |
| 09:55 | got a texto from tomeu that he has connectivity problems | |
| 09:55 | alsroot | anyway attention from design team early is a good point, /me planing to raise question about new journal on devel@ soon |
| 09:56 | erikos | alsroot: yes, that is good |
| 09:56 | tomeu | back |
| 09:56 | erikos | alsroot: I will note that in my email about the Feature Process, too |
| 09:56 | tomeu | will paste what got lost |
| 09:57 | (02:46:40 PM) tomeu: dsd_: it really sucks to try to address a problem with an UI change, then revert it in the next release, going back to square one | |
| 09:57 | (02:47:19 PM) tomeu: there's no point in having to release experimental UI changes given how easy is to modify sugar and publish a soas spin for people to try it | |
| 09:57 | (02:48:03 PM) tomeu: erikos: as I said, the problem is that the best date depends on the manpower we have in different areas, and that's difficult to appreciate | |
| 09:57 | (02:48:20 PM) tomeu: erikos: in gnome they have teams with clear leaders that will say if they can make the date or not | |
| 09:57 | (02:48:35 PM) tomeu: we lack those people in documentation, testing, etc | |
| 09:57 | (02:49:28 PM) tomeu: erikos: I'm just pointing out problems we have, not trying to shoot down any roadmap proposal | |
| 09:57 | (02:49:43 PM) tomeu: as you said, having agreed upon dates has already some value | |
| 09:58 | erikos | tomeu: right it is good to raise those issues |
| 09:58 | tomeu: and there is no value in the best roadmap, if you have no people walking them down | |
| 09:58 | tomeu: I will take care of the design team ping | |
| 09:59 | anyone who has contacts to testers? | |
| 09:59 | documenters? | |
| 09:59 | tomeu | I'm more worried about the deployment and testing teams than the design team |
| 09:59 | gary and eben are doing a good job leading forward | |
| 10:00 | erikos | ok, about deployment: what can we do here? |
| 10:00 | tomeu | well, I'm already dedicating some of my time to that kind of tasks |
| 10:00 | but that doesn't scale | |
| 10:01 | erikos | right, is it possible to coordinate that task? |
| 10:01 | I am a small deployer, what can I do to help? | |
| 10:01 | is something like that phrased out? | |
| 10:01 | tomeu | erikos: running biweekly meetings would be a great start |
| 10:01 | dfarning | The Spanish speaking local labs are starting to work together to create best practices for deployments |
| 10:01 | tomeu | that will bring more people onboard |
| 10:02 | dfarning: we have a critical lack of coordinators, but not of people doing stuff | |
| 10:02 | erikos | tomeu: coordinators is a good word |
| 10:03 | tomeu: we could do the job description things we were talking about before | |
| 10:03 | dfarning | tomeu, yes I have been waiting for a leader to emerge. |
| 10:03 | tomeu | erikos: sounds good, I'm very unsure about how best to communicate that |
| 10:03 | erikos | dfarning: maybe we need to clearly communicate that need |
| 10:04 | tomeu: wiki page and then post to the mailing lists | |
| 10:04 | tomeu: as a start I would keep it simple | |
| 10:04 | tomeu: but actually doing it | |
| 10:04 | dfarning | from past attempts at starting a deployment it is critical that the leader be a deployer not an 'sugar labs/olpc' person. |
| 10:04 | erikos | hopes the wiki gets back on, soon |
| 10:04 | tomeu | erikos: ok, we can repeat those calls from time to time |
| 10:04 | erikos | tomeu: right |
| 10:05 | tomeu | erikos: ideally we would have a community manager that would coordinate that :p |
| 10:05 | dfarning | I'll start nudging for a deployment team again. |
| 10:05 | erikos | tomeu: we should ask first for the community manager then :D |
| 10:06 | tomeu | erikos: ok, I guess we have an action item |
| 10:06 | #action erikos and tomeu to announce widely the need for a community manager | |
| 10:07 | erikos | tomeu: sounds good |
| 10:07 | tomeu | ok, let's get back to the agenda |
| 10:08 | anything else about the roadmap? | |
| 10:08 | erikos | I will announce it - the moment the wiki is up again |
| 10:08 | tomeu | nice |
| 10:09 | erikos | and announce as well the Feature Process |
| 10:09 | I cleaned up the policy yesterday | |
| 10:09 | I hope it is clearer now | |
| 10:09 | mainly rephrased it | |
| 10:10 | tomeu: so these things are mainly set up | |
| 10:10 | tomeu: now we need to use them | |
| 10:11 | any questions on that topic? | |
| 10:11 | tomeu | wiki is still loading here |
| 10:11 | of you will announce it _when_ the wiki is up again | |
| 10:11 | thought you were saying it was back | |
| 10:12 | erikos | oh, no :/ |
| 10:12 | tomeu | let's move this topic to the end? |
| 10:13 | erikos | the wiki won't be up soonish i think |
| 10:13 | i can wait another day before announcing | |
| 10:13 | after you read it | |
| 10:13 | next topic | |
| 10:13 | tomeu | erikos: oh, you haven't posted a notice already in the ml? |
| 10:13 | erikos | who is still here btw? |
| 10:13 | tomeu: I did | |
| 10:14 | tomeu | so I need to try to read it when the wiki is up ;) |
| 10:14 | erikos | yup |
| 10:15 | aleksey, thanksgiving at your end, too? | |
| 10:15 | tomeu | new features for 0.88? |
| 10:15 | erikos | curses about the imports of celebrations |
| 10:16 | CanoeBerry | aside: anybody know bernie's schedule today? i don't mean to spy on him, but i'm trying to get in touch with him in person in Boston if poss :) |
| 10:16 | erikos | tomeu: I have to phrase mine out first |
| 10:16 | tomeu | CanoeBerry: if I could contact him, I would tell him to fix trac and wiki |
| 10:16 | CanoeBerry | ! |
| 10:17 | tomeu | CanoeBerry: looks like solarsail is down |
| 10:17 | CanoeBerry | :( |
| 10:17 | erikos | tomeu: november despressions |
| 10:17 | CanoeBerry | We'll let him sleep a bit on Thanksgiving. His cell's off and voicemail full. |
| 10:17 | erikos | tomeu: very common in the server market |
| 10:18 | alsroot | erikos: nope, just revised dsd_'s patch |
| 10:18 | tomeu | CanoeBerry: which of his 20 phone numbers? :p |
| 10:18 | erikos | alsroot: nice! |
| 10:18 | tomeu | the best way to get people not to call you is to give them 20 different numbers from different countries and tell them to try one by one |
| 10:18 | CanoeBerry | if you need bernie's US cellphone, ask me privately |
| 10:19 | tomeu | CanoeBerry: I'm sure I have it already, the problem is to not mix them all |
| 10:19 | so we have no new features for 0.88 ;) | |
| 10:19 | CanoeBerry | It's +1 781-xxx-yyyy |
| 10:19 | tomeu | stabilization! |
| 10:19 | erikos | tomeu: yeah! |
| 10:20 | tomeu: right, code cleanup! | |
| 10:20 | tomeu | bring your nitpicks! |
| 10:20 | erikos | API cleanup! |
| 10:20 | where necessary... | |
| 10:21 | tomeu: what is about your current work? | |
| 10:22 | tomeu | erikos: moving forward, slower than I would like, not sure yet if it will be ready for 0.88 or for later |
| 10:22 | erikos | tomeu: ok |
| 10:22 | dsd_ | tomeu: do you have any tentative plans for what you will work on? |
| 10:22 | tomeu | it will be a pain to change something so low in the stack, but it's something we will have to face some day anyway |
| 10:23 | dsd_: after pygi no, but should be something well balanced between invasive and needed in the field | |
| 10:24 | as I said before, I'm not happy about big changes that won't impact positively on the field or that may have to be reverted in future releases | |
| 10:25 | erikos | tomeu: one thing I presented to aleksey is the 'Journal sync issue' of metadata |
| 10:26 | tomeu: open activity, change the description in the journal, close the activity | |
| 10:26 | tomeu: the description is gone | |
| 10:26 | tomeu | erikos: isn't that a matter of the activity listening for changes in the DS like the journal already does? |
| 10:26 | erikos | tomeu: feedback from my kids :D |
| 10:26 | tomeu | great |
| 10:27 | erikos | yeah, might be - i have not looked at the code yet |
| 10:28 | tomeu | ok, any other features we would like to discuss for 0.88? |
| 10:29 | rgs_, tch: 3G support? | |
| 10:29 | dsd_ | i'm planning to put forward OLPC mesh device support patch |
| 10:29 | but time permitting | |
| 10:29 | walterbender | erikos: if we incorporate my proposed feature to let one update journal entries from the acivity at any time, the sync problem doesn't go away but it is almost irrelevant. |
| 10:29 | dsd_ | any help appreciated, the code is rewritten it will just need a rediff |
| 10:29 | tomeu | dsd_: maybe .py could help there? |
| 10:30 | dsd_ | anyone, i'm not fussy :) |
| 10:30 | tomeu | dsd_: I think someone from .uy was also talking about working on that? |
| 10:30 | dsd_ | i havent heard anything |
| 10:30 | alsroot | has another 3 features to propose to 0.88 |
| 10:31 | dsd_ | i'm also looking for people to take on my content and font features |
| 10:31 | erikos | walterbender: yup, thought about that, too |
| 10:31 | tomeu | where is daniel castelo from? |
| 10:31 | dsd_ | but i'll probably implement about half of the font one this afternoon |
| 10:32 | tomeu | yeah, he is |
| 10:32 | so we have people from both .uy and .py working on that problem | |
| 10:32 | dsd_ | we do? |
| 10:32 | on mesh? | |
| 10:32 | tomeu | dsd_: no, 3g |
| 10:32 | dsd_ | ah ok |
| 10:32 | tomeu | .py seems to be one step ahead because they already implemented it with NM |
| 10:32 | .uy went with ppp, etc | |
| 10:33 | dsd_: I guess both .uy and .py are interested in the mesh stuff? | |
| 10:34 | rgs_ | tomeu: pong |
| 10:34 | tomeu | rgs_: have you read what we are discussing right now? |
| 10:34 | CanoeBerry | Will this meeting likely end in 30min? Just asking. |
| 10:34 | rgs_ | tomeu: i was out of context but tch left so I can state where we are in our effort to have 3G support |
| 10:34 | tomeu | rgs_: would be great |
| 10:35 | CanoeBerry: not sure, I can be more time if people want to extend on things | |
| 10:35 | rgs_ | tomeu: so the approach we would like to take is to make the minimum change on 0.84 to have 3G working |
| 10:36 | tomeu | rgs_: and how much would you like if that change come in the olpc-provided images as opposed to patching your own builds? |
| 10:36 | rgs_ | tomeu: from what I've learned of tch's research there is something with the way Sugar initiates it's dialog with NM that blocks us from being able to create 3G connections programatically as we are able to do from Gnome |
| 10:36 | tomeu: I believe that separated efforts are not a good idea | |
| 10:37 | tomeu: if .uy is working on something we better look for a general solution | |
| 10:37 | tomeu: patching are own build is a very last resource | |
| 10:37 | dsd_ | yes, sugar becomes the NM user settings service |
| 10:38 | rgs_ | tomeu: I think that by the end of today or tomorrow we could have a better diagnostic of how much effort would it take to at least make Sugar 0.84 allow an Activity to open up a 3G connection |
| 10:38 | tomeu | rgs_: awesome, erikos is our local NM expert |
| 10:38 | rgs_: and dcbw (NM global expert) is very helpful | |
| 10:38 | rgs_ | dsd_: so we need to extend the actual user settings service to be 3G friendly then |
| 10:38 | dsd_ | yes |
| 10:39 | tomeu | rgs_: I think integrating it in the shell would not be much more work |
| 10:39 | rgs_ | question is , do you guys think our effort is valuable? I.e.: will patches be able to make it into SL's official repo? |
| 10:39 | dsd_ | i think your only realistic option is to come up with a good 3G support implementation in sugar |
| 10:39 | tomeu | maybe even less work |
| 10:39 | rgs_ | dsd_: kk, |
| 10:39 | tomeu | rgs_: for master, totally |
| 10:39 | and I think dsd_ has already said he's ok with backporting it | |
| 10:39 | dsd_ | a control panel applet and whatever changes are needed for the backend |
| 10:39 | erikos | rgs_: of course |
| 10:39 | CanoeBerry | For 3G support, I'm clueless, but the Toronto guys have accomplished miracles here. |
| 10:39 | (Upper Canada College) | |
| 10:40 | rgs_ | dsd_: tomeu : nice, so its just a matter of keeping our head banging with the wall :) |
| 10:40 | dsd_ | well there is one other option - tell NM to ignore the device and do everything by hand |
| 10:40 | tomeu | CanoeBerry: I think that the non-sugar part has already been sorted out by deployments |
| 10:40 | dsd_ | and outside of sugar |
| 10:40 | rgs_ | tomeu: why backporting? I though dsd (olpc's) 0.84 branch == SL's 0.84 branch? |
| 10:40 | dsd_ | but having proper support would be a fun project for you |
| 10:40 | rgs_ | tomeu: dsd_ : on top of what codebase should be work? |
| 10:40 | dsd_ | master |
| 10:41 | tomeu | rgs_: because we would first apply to master, then backport |
| 10:41 | rgs_: if 0.84 gets a live on its own, it will be much harder for deployments to upgrade to later releases | |
| 10:41 | rgs_ | I am not sure I follow the terms.. master == HEAD (i.e.: 0.86) ? |
| 10:41 | tomeu | rgs_: 0.87, actually |
| 10:41 | rgs_ | tomeu: ah, ok |
| 10:41 | dsd_ | yes master is the git term for HEAD which is currently leading to 0.88 |
| 10:41 | tomeu | then we have a branch for 0.84 and another for 0.86 |
| 10:41 | rgs_ | tomeu: so we start with HEAD and then backport to 0.84, now I am synced |
| 10:42 | tomeu | rgs_: yes |
| 10:42 | since 0.84, only the adhoc stuff changed in that part of sugar | |
| 10:42 | I don't expect it to be hard | |
| 10:42 | rgs_ | tomeu: how hard would it be to backport? Has that part changed alot? |
| 10:42 | tomeu | backporting to 0.82 would be a totally different matter |
| 10:42 | rgs_ | tomeu: ah, ok |
| 10:42 | tomeu | because used NM 0.6 |
| 10:42 | rgs_ | tomeu: we are abandoning 0.82, so no need from us |
| 10:42 | tomeu | grat |
| 10:43 | CanoeBerry | 3G aside, just for reference -- these 3 stories summarize (some of) the tremendous accomplishments the Canadian group achieved getting cellular to work in Kenya: |
| 10:43 | http://www.olpcnews.com/conten[…]d_kenyan_s_1.html | |
| 10:43 | tomeu | dsd_, rgs_: so we need to coordinate with daniel castelo |
| 10:43 | CanoeBerry | http://www.olpcnews.com/countr[…]_solar_power.html |
| 10:43 | http://www.olpcnews.com/use_ca[…]and_kenyan_s.html | |
| 10:43 | tomeu | read those already |
| 10:43 | they did real good stuff | |
| 10:44 | rgs_ | tomeu: daniel castelo? |
| 10:44 | CanoeBerry | I'm in close touch w/ Mark Battley if you need him. |
| 10:44 | tomeu | rgs_: he's from .uy and was working on 3g support |
| 10:44 | rgs_ | tomeu: ah, great |
| 10:44 | tomeu: btw, .uy is planning on leaving 0.82 behind on 2010? | |
| 10:45 | tomeu | rgs_: no idea, but I hope so |
| 10:45 | oops, mailman is also down | |
| 10:45 | rgs_ | tomeu: ok, just to know if the effort justifies for them |
| 10:45 | tomeu | rgs_: maybe you can search your sugar-devel archives and read his posts? |
| 10:45 | rgs_ | tomeu: sure |
| 10:46 | tomeu | rgs_, dsd_: any of you want to take the task of coordinating with .uy? |
| 10:46 | to see if we can avoid duplicated work and pool resources on stuff such as the mesh support | |
| 10:46 | rgs_ | dsd_: we can do that. I think dsd_ is already very busy :) |
| 10:46 | tomeu | great, thanks! |
| 10:47 | rgs_ | dsd_: tomeu : erikos : and we'll come back with the tech questions when we start getting close some sort of design in order to implement this |
| 10:47 | tomeu | #action: rgs_ to coordinate the work on 3g and mesh |
| 10:47 | rgs_ | tomeu: ahhh, mesh? |
| 10:47 | tomeu | heh |
| 10:47 | rgs_: dsd_ has worked on that he would like to merge | |
| 10:47 | rgs_: I'm supposing both .py and .uy would be interested in that as well? | |
| 10:47 | rgs_ | tomeu: ah, ok. I thought that had been merged already |
| 10:47 | erikos | rgs_: nice, looking forward to |
| 10:48 | rgs_ | tomeu: sure, we would like to see that again |
| 10:48 | tomeu | rgs_: so it's a piece of work quite similar to the 3g stuff |
| 10:48 | touches the same code in sugar | |
| 10:49 | rgs_ | great, it'll serve as reference |
| 10:49 | dsd_ | yeah, mesh is represented by NM as a separate type of device |
| 10:49 | so its basically adding support for another type of network | |
| 10:49 | tomeu | rgs_: instead of both .py and .uy work on 3g support at the same time, you may want to split the work but help each other |
| 10:49 | dsd_ | so now sugar supports 802.11, ethernet, olpc mesh, and hopefully 3G soon |
| 10:49 | tomeu | so acquire knowledge globally and share it regionally |
| 10:49 | rgs_ | :) |
| 10:50 | tomeu | or who knows, maybe .uy wants to hire paraguay educa to do that work ;) |
| 10:50 | whatever as long as the work gets done and everybody can benefit | |
| 10:50 | rgs_ | yeah |
| 10:51 | tomeu | ok, so next topic? |
| 10:51 | alsroot: let' move to your feature proposals? | |
| 10:51 | rgs_ | we think 3G will be of great help, teachers really want to keep connected with us and sometimes they can't reach schools after school time. Same for families |
| 10:52 | tomeu | rgs_: yeah, it's great the rate of penetration that is achieving 3g in many countries |
| 10:53 | walterbender: what about your features? | |
| 10:54 | alsroot | thinks to implements: 0install integration, sugar bundles(unified transfer wrapper for various sugar content) and Journal plugins |
| 10:55 | erikos | alsroot: journal plugins include the different views? |
| 10:55 | alsroot | erikos: yup, eg thumbs |
| 10:55 | erikos | alsroot: nice |
| 10:55 | alsroot | ..or something sompicated like shared collections of objects |
| 10:56 | unfortunately wiki is down.. | |
| 10:56 | most UI invasive is Journal plugins | |
| 10:56 | walterbender | has anyone tried pinging bernie? |
| 10:57 | erikos | walterbender: CanoeBerry did |
| 10:57 | alsroot | erikos: btw in case of UI features, we can have separate section in template |
| 10:57 | tomeu | walterbender: yeah, CanoeBerry tried to call him |
| 10:57 | erikos | alsroot: right, that is what I meant |
| 10:57 | dfarning | walterbender, yes via mail, irc, and phone |
| 10:59 | alsroot | ah and tags as well, as a part of Journal plugins implementation |
| 11:00 | CanoeBerry | Found Bernie.. |
| 11:00 | dfarning | tomeu, I would still like to nudge you towards starting to defining fructose. |
| 11:01 | alsroot | more likes word "eliminating" :) |
| 11:01 | tomeu | dfarning: the problem with me defining what fructose is is that people don't agree with it :p |
| 11:02 | walterbender | tomeu: we should decide if Fructose exists for the convenience of the Sugar team, the Activity team, or the Deployments |
| 11:02 | dfarning | yes, but the definition is alot like a release cycle.... It is a starting point for coordination efforts and communitation. |
| 11:03 | tomeu | for me, fructose are those activities that agree with using the sugar release process in exchange of better support from the community |
| 11:03 | walterbender: activity team, in my view | |
| 11:03 | CanoeBerry | Bernie on his way. |
| 11:03 | tomeu | or even, individual activities |
| 11:03 | dfarning: right, you put in better words than me | |
| 11:03 | walterbender | tomeu: I agree. or somewhere between the Activity Team and Deployments and Distros |
| 11:04 | alsroot | likes scheme then SL(as organization) provides only core - glucose+SP |
| 11:04 | tomeu | walterbender: it brings benefits ultimately to deployers and users in general, but it's because activity authors make use of it |
| 11:04 | dfarning | tomeu, just like the release cycle, it can change and evolve as we get more resources and things move forward. |
| 11:04 | walterbender | alsroot: well... SL provides that and SL also provides a framework for activity developers |
| 11:05 | alsroot: but activity development can happen outside of SL as well | |
| 11:05 | tomeu | right |
| 11:05 | alsroot | hmm.. core is the framework |
| 11:05 | and not sure how "but activity development can happen outside of SL as well" relates to removing fructose | |
| 11:05 | tomeu | alsroot: I think he referred to framework as a set of processes, not in the engineering sense |
| 11:06 | walterbender | was motivated to maintain an activity in Fructose both for the discipline of a schedule and the hope that it would lead to better interaction with the i18n team |
| 11:06 | found the former to be the case, but not the latter :( | |
| 11:06 | bernie | walterbender, CanoeBerry: hmm... something's wrong with apache on solarsail |
| 11:06 | it already happened once | |
| 11:06 | tomeu | walterbender: I think that's because of our lack of coordinator manpower |
| 11:06 | walterbender: it works in other projects | |
| 11:06 | alsroot | walterbender: but in case of fructose we hace 1st class activities and other |
| 11:07 | walterbender | alsroot: I think it behooves SL to make sure that the environment for activity developers is available... e.g., ASLO |
| 11:07 | alsroot: and it SL gets too far removed from the needs of activities, we will undoubtedly become obsolete | |
| 11:08 | alsroot: so we need some framework for keeping activity developers in close communication with the core Sugar team (Glucose) | |
| 11:08 | alsroot | walterbender: I think you are messing different things, im my mind remiving frustose doesn't mean deploying to users only glucose, deploying to users is a task for deployers(even if they are SL members), |
| 11:08 | walterbender | alsroot: I am in favor of eliminating Fructose |
| 11:09 | tomeu | those who wish, I still hope lots of activity development to happen totally independently. but our users will benefit from a reduced set of activities with higher quality |
| 11:09 | alsroot | tomeu: yup, and we have not so hard ways, e.g. on ASLO -editors peaks |
| 11:10 | walterbender | tomeu: yes. if we can manage to keep a small core of key activities of high quality, that would be appreciated by the deployments... |
| 11:10 | alsroot | walterbender: removing fructose, for me, makes SL's strategy cleaner from tech POV |
| 11:11 | walterbender | alsroot: I think the activity team should take it over and operate it independently of Sugar/glucose releases... |
| 11:11 | tomeu | for me the question is: can we help activity authors to work better with documentation writers, translators, marketingers, etc. without them following our release cycle? |
| 11:11 | alsroot | ..and we don't loose any final deployng strategies, e.g. soas will deploy the same set of activities |
| 11:11 | walterbender | alsroot: but it would be to their (activity team) advantage to track glucose closely |
| 11:11 | dfarning | I think we are talking about a couple of different separate yet related issues. I'd like to listen to the rest of this dicussion and write a post to devel@. |
| 11:12 | alsroot | walterbender: my concers, we have many ways to track such activities(fructose, ASLO) but we dont have enough peopele to use all these ways :) |
| 11:12 | walterbender | alsroot: valid concern... |
| 11:13 | alsroot | ..so I think using ASLO's editor way is preferable, since its cleaner |
| 11:16 | tomeu | btw, do we agree this is a matter of the activity team? |
| 11:16 | alsroot | +1 for me, since its about activities |
| 11:17 | CanoeBerry | bernie: don't forget you're paid triple-wages for yr hard work on Thanksgiving day. See you dinnertime!! |
| 11:18 | bernie | CanoeBerry: :-) |
| 11:18 | CanoeBerry: seth should be coming to | |
| 11:18 | CanoeBerry | Cool |
| 11:22 | tomeu | let's move to 0.84 maintenance? |
| 11:22 | dsd_ | sounds good |
| 11:22 | tomeu | is unmadindu with us? |
| 11:22 | unmadindu | yep |
| 11:22 | tomeu | any doubts? anything not clear in the emails that have already been exchanged on this? |
| 11:24 | unmadindu | not from my side |
| 11:24 | dsd_ | i have one thing i'd like to comment on |
| 11:25 | we (olpc) discussed this together | |
| 11:25 | and while of course its our responsibility to be responsible for what we ship and help out with the maintenance | |
| 11:25 | there are also floating concerns about this because it feels like we're (almost) alone on this front | |
| 11:26 | i.e. everyone who was involved in the core development of sugar 0.84 is no longer developing or maintaining it | |
| 11:26 | tomeu | I don't think it's a white or black issue |
| 11:26 | dsd_ | so we'll certainly be very grateful for any help on this front :) |
| 11:26 | tomeu | resources are limited and not all needs can be satisfied at once |
| 11:27 | dsd_ | right, but its a pretty big need that seems to be getting close to zero attention |
| 11:27 | tomeu | between the two extremes of not touching stable releases and stopping new releases is a lot of ground |
| 11:27 | dsd_ | having users is a pain.. :) |
| 11:27 | tomeu | yeah, we were much better in the trials age ;) |
| 11:29 | dsd_: you know that there are many more engineers working downstream than upstream. upstream has made repeated calls to get those people involved up there so that resources are better used, but we need to understand that there are several circumstances that make that a slow process | |
| 11:29 | hopefully, we are seeing progresses there | |
| 11:29 | dsd_ | from my personal deployment experience i dont see it as a realistic expectation that deployments will get involved with sugar development |
| 11:30 | tomeu | well, volunteer-based development is not more realistic, I think |
| 11:30 | dsd_: what about what we discussed before about 3g and mesh support, you don't think those efforts can suceed? | |
| 11:30 | dsd_ | i think that is the exception |
| 11:31 | raul and martin are sooooo much more technically capable than any other people i have met who work on deployments | |
| 11:31 | tomeu | well, if 0.88 had only those features but were developed by the deployments, I think it would be an enormous step in the right direction |
| 11:31 | dsd_: I don't think all deployments will contribute in the same way | |
| 11:32 | there's no need for that | |
| 11:32 | also, deployments are already pooling resources in some ways, and can learn to pool resources in more ways | |
| 11:33 | if all deployments in asia decided to put each some money to hire someone to improve script support in sugar, do you see that so unfeasible? of course, first we would need to have them speaking to each other | |
| 11:34 | I think that one year ago, what I'm saying could have been seen as more unrealistic | |
| 11:34 | dsd_ | lets move on |
| 11:35 | i was just making a comment | |
| 11:35 | tomeu | well, that's quite closely tied to maintenance of stable releases, right? |
| 11:36 | dsd_ | yes, its a comment about that |
| 11:36 | tomeu | so I think that we shouldn't create too big expectations on volunteers |
| 11:36 | dsd_ | ok |
| 11:37 | tomeu | not because cannot achieve lots, but because it's hard to plan on that |
| 11:37 | dsd_: let's get back to this in a few months? | |
| 11:37 | dsd_ | sure |
| 11:37 | tomeu | for now, moving on the NM features and you taking care of 0.84 seems like a good step forward |
| 11:37 | dsd_ | and if you have any time and interest in 0.84 at any point, your help would be much appreciated |
| 11:38 | tomeu | dsd_: well, you already said you want stuff in master first, so that puts pressure on me to work on issues deployments care about |
| 11:38 | so i will be helping from that end and answering questions, etc | |
| 11:39 | dsd_ | so is there more discussion that needs to happen or can we get started on this? |
| 11:39 | tomeu | dsd_: would like to get the maintainers to give their ok in the ml |
| 11:39 | I will do so for my modules | |
| 11:40 | dsd_: please ping the others if needed | |
| 11:40 | dsd_ | ok thanks |
| 11:40 | tomeu | hmm, what else... |
| 11:41 | erikos: maintenance? | |
| 11:41 | erikos: can you expand on what you mean by that? | |
| 11:46 | ok, so maybe finish now the meeting and discuss that in the ml and/or next meeting | |
| 11:46 | thanks all for your patience on this slow meeting and see you in the next one | |
| 11:46 | #endmeeting |