[IAEP] XO Special interest group at Sugar Labs
dsd at laptop.org
Mon Sep 21 23:54:07 EDT 2009
2009/9/21 David Farning <dfarning at sugarlabs.org>:
> The project is starting with work flow focused goals.
> 1. Create a team.
> 2. Create a release cycle.
> 3. Start cranking out releases each one better than the last.
> The missing gap in the current Sugar-> distro-> XO workflow is that
> CJB is working from the deployment and hardware back to the distro and
> Sugar. This is both necessary and exactly what OLPC _needs_ Chris to
> focus on. (Think of the relationship between redhat and fedora)
> But, he and the entire ecosystem would benefit from a time based
> release focus upstream. That way they can pick an upstream and spend
> six or eight months making it deployment ready rather than starting
> from scratch every year or eighteen months.
I don't understand this. How is what you are proposing different from
what has been done before, and is happening now?
When are we starting from scratch?
> It would be great if you would bring your work into the project. As
> far as I can tell, you and Chris are the two most knowledgeable people
> working on this problem. Not sure what your time available is:)
> Hopefully, we can build a tight team to make your work more widely
> The goal is to provide a place where the various people working on
> 'upstream' XO, disto, and Sugar issues can come together, tighten
> focus, and make their work available to the widest possible audience.
I think we have most of those things quite well covered already:
- we have mailing lists for coming together, which are already being
used for this purpose
- we have hosting from OLPC
- Stephen Parrish appears to be a focused buildmaster
I think what's missing is developers and/or high-calibre testers who
are able to provide detailed technical diagnosis of bugs. If your
group could bring in some of those resources, it would be of huge
I don't feel that a release cycle would be that useful. At least to
me, that implies that you'll spend some time on feature development,
then close that off for bug-fixes only as the release date nears.
Well, really all the features have been developed already, and the
only thing left is bug fixing anyway. And the couple of features that
are missing are big regressions for deployments. I would think that
putting a date on a release and closing the door to the feature
regressions is not really going to do anything positive at this stage.
More information about the IAEP