On Wed, Jul 23, 2008 at 06:27:59PM -0700, John Gilmore wrote: > > > 2) Sugar would run more smoothly on-XO if jhbuild were retired. > > I think this is a good point in the abstract. Do any frequent contributors > > *not* have an XO? > > I approve of retiring jhbuild, and handing out XO's to Sugar > contributors, but you've really got the question backwards: > > => Do any frequent contributors have ONLY an XO? <=
Yes, I've taken it on a tangent, as I promised in my boilerplate. Thanks for getting back to the topic. Is the question really best phrased as you did? Are you really asking "should the contributor community only use XOs"? It seems you're asking "how can we turn our XO deployment kids into contributors", which is a great question. I think the way forward is to raise some awareness (as you're doing) and constructively move the discussion forward. > I've seen lots of high flying rhetoric about Sugar being maintainable > and extensible by kids with their XO's, because it's in an easy > interpreted language shipped in source, etc. You have almost 500,000 > units in the field (admittedly in younger kids). Seen any Python > prodigies contributing yet? The sound-bite rhetorical question distracts from your later good points. Especially given the point is educating kids, I'm not so concerned that kids learning english and maths haven't sent sugar patches in yet :). > But the tools needed to be a contributing part of the Sugar community > don't run on the XO. [...] > Merely installing the change without trashing his XO's entire GUI > with a typo or missing Python file is tricky. Indeed! How can we as the community improve the extensibility while letting the core people get on with developing the core (and yes, I know the core has to be extensible, and I think it's good to keep raising the point; but we also need to *do* something about it - any ideas? I would be very interested in working on some, and coming up with some when I'm finished my one or two patches I'm working on now). > If we want the kids who *love* their machines to come to *know* and > *evolve* their machines, there's a lot more work to be done. Indeed. I quote this not for the mindless "me too gnu++ kthx" but to highlight it more - I think it gets lost a bit in your detailed points. > In many ways the unique XO UI and collab setup make the learning > curve steeper, not easier. I don't know this to be true, and I suspect it to be a distracting falsehood. But let's try to address the more fundamental issues (like no diff / diff-like utility / tools) you raised earlier. > John > Sugar is hung up in its own maintenance > machinery. I don't think you (only) mean Sugar here. Very interesting comments, btw. Thanks. Martin
pgpjJBMMDtQIN.pgp
Description: PGP signature
_______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
