[IAEP] Long-term development strategy (Was: New XO-1.5 10.2.0 build 119)
pbrobinson at gmail.com
Mon Apr 12 18:54:40 EDT 2010
On Mon, Apr 12, 2010 at 11:12 PM, Bernie Innocenti <bernie at codewiz.org> wrote:
> On Sat, 2010-04-10 at 13:29 -0700, Jon Nettleton wrote:
>> Has there been any discussion on whether CentOS was an option as a
>> base for the distro? With RHEL/CentOS 6 hopefully within sight, that
>> would give a nice target to provide both the combination of stability
>> and long term support.
> This comes up every once in a while. Frankly, I don't "believe" in the
> value of enterprise Linux distributions; I've been stuck with them in a
> couple of cases in the past, and they were always a support PITA even
> for non-development usage: nobody in the community cares to help you
> with debugging and back-porting recent versions of software becomes
> increasingly painful over time.
> Granted, frequently upgrading the OS also comes with its own aches too,
> but these are amply compensated by useful new features and better
> support from upstream.
> We've been very lucky that Dan Williams was kind enough to spend some of
> his time for helping us with critical bugs in NetworkManager 0.7. We've
> not been equally lucky with udev and GStreamer, both of which have
> unsolved issues in F11 for which we lack expertise.
> Over the last 5 years, I've become a strong advocate of the
> decentralized, community-driven development model. I do believe in it
> because I've observed it at work for 15 years. Traditionally minded
> managers are still looking at this enormous market value accumulated by
> the open model as some sort of economic anomaly; some sort of prestige
> trick which contradicts the rules of classic schoolbooks. Yet, an entire
> industry of new businesses has grown out of free software and is
> flourishing with it. Those who guessed its rules can play the game and
> As Martin and I discussed not long ago, our development model doesn't
> have to directly affect end-users. Already released free software
> doesn't have an expiration date. Conservative users can keep using Sugar
> 0.82 forever, if they really like it better than newer releases.
> Bugfixes and new features could be back-ported from newer releases, of
> course with increasing costs as time passes.
> We OLPC & Sugar developers cannot effectively support the entire
> codebase of an entire OS without strong backing from the larger Fedora
> community and the even larger global Linux community.
> In the past, Sugar and OLPC development was much hurt by its
> disconnection from the rest of the free software ecosystem on which it
> was built. We need to get much closer to our upstream projects, both in
> time (by using current software) and in space (by not diverging our
> codebase). It's not just a technological issue, it's a long-term
> sustainability issue.
> Before anyone yells "Yarr! Ye don't care about the children!", I'd like
> to point out that I've been spending several months looking at problems
> in the field, trying to fix some of them and, more importantly, trying
> to build local capacity for fixing them autonomously. In my mind, this
> is *the only* reasonable strategy to scale Sugar support up to the size
> of an entire planet. Those who think it would be impossible for people
> in developing nations to learn the technical skills needed for fixing
> their software would be shocked to see what Nepal and Paraguay have been
> able to achieve in just two years, with very little funding.
Bernie, I'm not sure the point of this point at this point in time. To
copy and paste part of the response I did to the other thread on
fedora-olpc for others benefit.
I personally don't see the point discussing it because from where I
sit I believe it will be supported well in both and continue to be so.
That way people have the choice. It might well get to a stage where
the newer versions of sugar won't run in RHEL/CentOS due to whatever
deps at which point we get to a situation where that release becomes
like 0.84 is currently and is a long term support release. I don't see
why its hard to support both because its not. The package maintenance
is simple and is done easily by a couple of people. There will be
Fedora and it will continue to be supported in Fedora for the
developers and the like that want the bleeding edge and then there
will be the EL branch for those that don't like so much blood. Its
called choice. There's no reason to limit it. There's not much point
discussing it at the moment as RHEL-6 isn't out yet, yes its in beta
but its not out.
In short RHEL-6 isn't out yet, the associated CentOS6 release is quite
a while away as a result. Also ARM isn't a supported platform there.
Sugar is about options and I think having both options will be of
benefit to different users. I believe the leading edge Fedora will
continue to be a platform for development and then others in the know
or deployments themselves can make the decision as to what's best for
More information about the IAEP