[Sugar-devel] Long-term support for Sugar

[Bernie Innocenti]

El Mon, 21-09-2009 a las 16:33 -0400, Bill Bogstad escribió:
> The lack of good dependency reporting and version tracking for
> Activities makes this difficult.   Something like XO bundles could
> work better for  for some scenarios though.

If it were on me, I'd just ditch the XO bundle format and use native
packages for each distro.  Some are already being packaged, and the
Python distutils are capable of producing rpms and debs with the same
ease of our current setup.py scripts.

It's been discussed several time, but the consensus seems to be that the
XO format will stay around for a while :-(


> For example, has anyone ever done anything with the 'host_version'
> field in the Activities *.info file?  Maybe it could be hijacked for
> Sugar library dependencies. Not as remotely capable as full dependency
> checking, but core Sugar (glucose) could at least use this for direct
> Activity dependency issues.  Preferentially with a pop-up telling
> people there may be incompatibilities.  Activities that stick with
> direct Sugar supplied functionality would be safe.  Glucose would know
> what range of values it supports and would alert if an Activity is
> outside of that range.  Activities would request the minimum value
> that works for them in their info file. Perhaps Activities could also
> query for the maximum value supported and change their behavior based
> on it.  (This assumes that Glucose functionality is monotonically
> increasing and the cost of retaining compatibility with older versions
> of the Glucose API is reasonable for at least a few releases.)

Oh, no!  Let's not go down this way.  Pretty please?

It took 10 years for the Linux distros to mature their packaging
infrastructure to the point it became really usable by end-users.  This
includes all the tools for building binaries, dependency solving,
repository management, build clusters, QA and, finally, good UIs.

Now that the path is clear, it might take only 5 years of development
to start over from the XO bundles.  I'm unable to estimate how many
full-time developers it would take, though.

OR, we could pick the native distro packaging systems off the shell and
make the necessary changes to make them work slightly differently as
needed.


> So clearly teachers/schools aren't Sugar Labs' target for its'
> deliverables because their desire for stability is incompatible with
> the fast changing, (almost) never look back release model of Sugar and
> Fedora.  I'm glad that we cleared that up.... :-(

The word "stability" in software is mostly a marketing term with no
technical substance.  It also means wildly different things depending on
the user you ask to.

Some users would call stable an old version of Windows 98 that blue
screens all the time, because it has just the bugs they're familiar
with, and none of those they're not yet used to.

I have been running CentOS and RHEL on some servers, and they were a
complete PITA.  For example, my usual backup scripts were hitting an
rsync bug that was fixed years ago.  Oh, and I had to manually install
the web applications I actually needed from source... because the
versions bundled with the "stable" distros were amazingly old.  But if
you resort to manual installations, don't you also loose all the
advertised stability and the benefits of long-term support?

Modern distros with 6 months release cycles are getting better at QA.
Even Fedora is no longer the bleeding razor blade that it used to be.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/