[Sugar-devel] [IAEP] Future of Zero Sugar
alsroot at member.fsf.org
Tue Dec 15 08:36:54 EST 2009
On Tue, Dec 15, 2009 at 10:52:56AM -0200, Tomeu Vizoso wrote:
> On Tue, Dec 15, 2009 at 04:07, Aleksey Lim <alsroot at 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
> > * 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
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. 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.
More information about the Sugar-devel