On 15 Dec 2009, at 13:36, Aleksey Lim wrote: > On Tue, Dec 15, 2009 at 10:52:56AM -0200, Tomeu Vizoso wrote: >> On Tue, Dec 15, 2009 at 04:07, Aleksey Lim <alsr...@member.fsf.org> wrote: >>> On Tue, Dec 15, 2009 at 10:16:02AM +0545, Bryan Berry wrote: >>>> I strongly agree w/ tomeu on this. >>>> >>>> Making Sugar easier to contribute to isn't anywhere near the top of the >>>> list >>>> of requested features by our kids and teachers in Nepal. >>>> >>>> The far and away most requested feature by teachers in Nepal is a mechanism >>>> for kids to "turn in homework." I am not talking about invasive testing >>>> here. The typical Nepali teacher just wants to know which students out of >>>> 50-70 kids are failing to understand basic concepts. >>> >>> I absolutely agree with such points, but: >>> >>> * as a 3rd party developer, I don't see such teachers requests listed >>> somewhere on wiki, that let me see what can I do and peek most >>> interesting/suitable-for-my-skils/etc task >> >> I'm painfully aware of this situation and have been spending my >> energies on this problem for already a good while. Our colleagues at >> Uruguay and Paraguay are already working on upstreaming their >> developments, but are also going to work with us in identifying the >> most pressing needs in deployments. Have already some ideas about what >> to work on, how do you think we should track them? > > Since we have nothing for now, any movements are welcome. > > In my mind having wiki page(one page with links to subpages, or category) > is enough, the major things I'd look for is is having > priority(deployment schedules etc), summary/description and contacts > (having irc contact would big plus). > >>> * I'm feeling huge discomfort as a developer when I need to package >>> binary blobs to my .xo, w/o instrument which let me unify >>> installing/upgrading process of such non-SP/specific-to-my-activity >>> dependencies >> >> I agree this is a problem, but also think that many activities >> shipping binaries don't actually need them. Bindings for libraries can >> be written in ctypes, without need to use a .so. >> >>> * I'm feeling less(but still big) discomfort as a developer when I >>> don't have standard method to share my core related changes, >>> for-testing-purposes/to-show-what-I-have-in-mind, well "please, attach >>> my cloned repos, install them" still works but not so attractive for >>> users >> >> What about generating a SoaS (or Trisquel, etc) image with such >> changes? This is something that can be done today without so much >> trouble. >> >>> * implementing Zero Sugar initiative, in my mind, is providing >>> "fishing-rod" for developers/doers instead of "feeding" users >>> thus has prime priority >> >> I don't see things so black and white. I have been working on this >> same problem for a while now (view source key, extensions, etc) and >> our users are taking advantage of at least the extensions facility. We >> are going to see patches very soon for keybindings, device icons and >> control panel sections. And that code can be already deployed without >> waiting for upstreaming because of the extensions mechanism. >> >> So _today_ we have empowered users that are deploying shell extensions >> without disrupting the rest of the shell, and simultaneously are >> working with the community and sharing the fruit of their work. >> >> The technical part has been in place since a year ago, but the trigger >> for this to happen has been actually social interaction. There's no >> point in making our platform super-hackable if we don't work as well >> in the non-technical part of the problem. > > Just to be clear, the technical part of Zero Sugar is > http://wiki.sugarlabs.org/go/Activity_Team/Services > its not something huge, just a set of declared rules how to work with > external(to activity or SP) dependencies. Code is ready for first > release usage and I'm going to spend this week(and looks like next) to > prepare proper docs/tutorials/infrastructure and remove blobs from all > ASLO activities.
Woooaaahhh... Removing binary blobs from all ASLO activities!? Now I'm no fan of having to include a binary blob (I avoid it if I have any choice), but Sugar is not targeted at an environment of always on internet cloud computing. An activity must be a self contained, sharable bundle for 99% of our users, needing no downloads of eternal resources at first run/install. I'm most happy to see some smooth fallback mechanism for the 1% running some hokey-pokey hardware/software platform, but resources (binary or otherwise) for our majority use cases should live inside activity bundles. Regards, --Gary > That's my strong intension and not only as a developer > but also as a ASLO editor - I think we should stop posting bundled > binaries to ASLO as soon as possible. _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep