On Wed, Aug 19, 2009 at 06:52:07PM +0100, s...@reboot.sh wrote: > that problem, could be summarized into something like ... > > The (distro) timed release model at large - specially for desktop > plays - doesn't work, much less scale, for practical reasons : there > are tons of oss projects with tons of development models, completely > disparate release schedules, that will never ever agree on global > matching release schedules. This has profound implications, which > often imply planning within 2/3 releases of advance, gets too much > 'innovation' packed into small times slots, as end users, get to > digest too much stuff/change at once, at time of every major distro > release, and overall, IMHO, it ends slowing down the overall pace of > (open-source software) innovation, as it either increases latency > (with newer stable stuff being delivered later, sometimes _years_ > later, which is bad, or getting into the public, into > pre-release/unstable form - to meet distro schedules/deadlines, > which isn't good either). > > > Then, _our_ attempt of a solution to that problem would be formulated > into something like ... > > to build/maintain, using 'stock/upstream' a distro, _suitable_ to > end users, in a way that all its different building blocks, could be > managed asynchronously, while maintaining overall consistency, i.e. > being able to at, any given time, update/touch/modify any part of > the whole stack without breaking it.
The only question is: which end users? Some users (classic release users?) are happier with occasional times of large changes with longer periods of stability in between. Others (agile users?) prefer to have smaller change more often. I'd say that Foresight can succeed at making agile users happy, given focus and commitment. While in theory Foresight could grow an offshoot that makes classic release users happy, I don't think that's the point. >From my personal point of view, being explicit about which of these groups Foresight focuses on will make a lot of things easier. Having one or more classic desktop-oriented distributions packaged with Conary which follows the classic release model would take pressure off of Foresight to serve both masters. This is completely orthogonal to the question of any separate base OS on which to base Foresight. I think that we've heard at least a few excellent arguments in favor of the full source rebuild, using sources eclectically. I think that António states here why that's useful for Foresight, but I'd like to restate it in drastically different language: it extends the concept of "desktop" all the way down into the Foresight OS, instead of conceiving of it as a shell over a classic OS. Given those arguments, I'm very interested to see the results of António's work on rebuilding from source. _______________________________________________ Foresight-devel mailing list Foresight-devel@lists.rpath.org http://lists.rpath.org/mailman/listinfo/foresight-devel
