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

#sugar-meeting, 2009-11-26

 « Previous day | Index | Today     Channels | Search | Join

All times shown according to UTC.

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

 « Previous day | Index | Today     Channels | Search | Join

Powered by ilbot/Modified.