I think a lot of the frustration around the journal could be abated by publishing a roadmap with actual projected times when each feature is planned to be available for testing in a joyride and then projected release number. Many of the experiments and research-type proposals have sounded excellent as fixes or at least mitigations for the journal's underlying problems. But from the outside perspective what I see reading conversations about this on the list is a sense that there are true believers inside the olpc and sugar development team that hold to a belief that a great day is coming for the journal, but without a concrete roadmap making that belief real to those only experiencing the difficulty in dealing with what is there right now, they sometimes sound a bit delusional. (Not saying that they are...it's just a big mismatch between pie-in-the-sky pictures of a cloudy goal and no visible stepping stones to that goal).
One thing that might help is a wiki FAQ about the journal collecting a roadmap and pointers to the work that has taken place already in one place. On Thu, Oct 9, 2008 at 11:30 AM, Michael Stone <[EMAIL PROTECTED]> wrote: > On Thu, Oct 09, 2008 at 12:55:43PM -0400, Erik Garrison wrote: > >You acknowledge that the system is not functioning as well as it should > >be in its curren state. Please stop saying "we are going to do this" > > Instead, please stop saying "we are going to do this" and just do it and > be done with it! > > >and look for the simplest way to achieve a usable system for our usesr. > > Your arguments are impassioned but not persuasive. Please accept the > fact that a cadre of People Who Have Shipped Software believe that > making a good Journal is worth attempting one more time. If their choice > proves faulty over the next six months, then you will be in a stronger > position to argue your case; if not, then I believe the issue will be > moot. > > >I will gladly help in this endeavor, but I am concerned by our security > >system and the frequent implications that we are holding to old designs > >that my ideas and motivation have no place in this effort. > > Either cite specific concerns or desist from raising this issue. > > >I don't think we can incorporate the concept of memory and forgetting > >into the Journal in a programmatic way. Forgetting is as much a learned > >skill as remembering, and attempting to replicate it in software seems > >like a very difficult, if impossible, task. > > Attendees of the previous Journal Summit: please write down the > algorithm you constructed for forgetting so that Erik can evaluate it. > > Erik: in the mean time, please tender opinions on [1] since this topic > has been dealt with before by others. > > [1]: > http://www.cs.ubc.ca/~feeley/papers/1999-4.pdf<http://www.cs.ubc.ca/%7Efeeley/papers/1999-4.pdf> > > >I feel that we are tilting at windmills if we believe we can reliably > >produce something so incredible in any conceivable timeframe. > > I believe that we have already produced something incredible, including > but not limited to shipping or making available > > * power management capable of yielding 10-hour battery life > * essentially all activities filesystem-isolated by default > * a bandwidth-efficient atomic update system w/ rollback > * a first-boot activation and passive-kill system which still permits > the laptops to be fully unlocked at user request > * a document-centric paradigm which was sufficiently compelling to > inspire a document-centric GNOME summit > * a distribution with a deep commitment and impressive support for > multi-locale usage and for usage by illiterate users. > * an implementation of the 802.11(s) draft spec > > to an installed user base on the order of 500K users. > > We have also constructed but not yet shipped or shipped demo-quality > implementations of: > > * demo-quality networked collaboration software good enough to spur > real interest > * a revised Journal, > * an indexed versioned content-addressed filesystem, > * network isolation, > * efficient multicast wireless data and presence transport, > * server-side jabber event filtering and searching > > Finally, we have substantial design and requirements documents waiting > for implementation in each of security, networking, and the UI. > > In conclusion, given how far we've come in the past two years, I > sincerely hope that we continue to attempt the same task for the next > two years. Where is your evidence that we're taking on too much? > > >I am furthermore frustrated by the tight integration of the Journal into > >the window manager. > > Please point to the integration between the journal and the window > manager which bothers you. I do not believe any substantive integration > exists between those components (though I acknowledge the integration > between the shell and the window manager and between the shell and > the journal). > > >In particular, our security model has the effect of preventing work on > >this issue that isn't supported by all the core developers. > > Scott seems to be suffering from no impediment from our security model > so please explain your complaint in more detail or > > rm /etc/olpc-security > > and get on with life. > > > We can only have one file management application. > > We presently intend to _ship_ only one filer. We'd be happy to have a > choice about which one to ship, though. > > > I am afraid that I or another interested developer will implement such > >systems but find they are rejected by the core developers, > > Shall I quote Roosevelt or Palpatine? > > > and it will be impossible even for users desire to use them to easily > > do so. > > This is a separate problem; please treat it as such. > > (Mildly) frustratedly yours, > > Michael > _______________________________________________ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > -- "The water won't clear up 'til we get the hogs out of the creek." -- Jim Hightower
_______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel