[Sugar-devel] Tracking upstream versions with sugar-jhbuild (was: Re: Simplifying sugar-jhbuild)

2009-05-22 Thread Sascha Silbe

On Thu, May 21, 2009 at 10:03:09AM +0200, Tomeu Vizoso wrote:


1) Stop checking out random unstable versions of external projects.
They break very often, and we cannot fix them.  Let's instead 
upgrade

manually every once in a while after some testing.

We are supposed to be doing this already, [...]

Are we? The first line of the Jhbuild wiki page still reads:

Sugar-jhbuild will automatically download the latest of Sugar's 
dependencies as well as Sugar itself directly from their source 
repositories, rather than relying on source packages that may have 
become stale.


To me, changing this is a policy decision, so I'd like to have a broader 
discussion about it.


Advantages:
+ less frequent breakages (only on manual updates)
+ maybe less total number of breakages (because some of them might be 
already fixed in the meantime)


Disadvantages:
- we discover incompatible upstream changes only after a while when 
upstream is less likely to change it

- regular manual updates needed
- need to track security updates and apply them ASAP (already a 
nightmare for xulrunner)



An option might be to use different modulesets in parallel (latest deps 
+ latest Sugar, stable deps + latest Sugar, stable deps + stable Sugar) 
and have BuildBot instances for all of them. That way developers can use 
a reliable system, but we still get notified of upstream breakages 
early.


We already use distro packages wherever possible, BTW (*). So this is 
just about packages where the distro version (if any) is unsuitable to 
Sugar, usually either because it's an old distro version or we're 
relying on very recent features.



(*) If you find out that for any package we currently build on our own 
the distro version in fact suffices, please file a bug against 
sugar-jhbuild. I have little to no information about which versions or 
features we actually need.


CU Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/

signature.asc
Description: Digital signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Tracking upstream versions with sugar-jhbuild (was: Re: Simplifying sugar-jhbuild)

2009-05-22 Thread Tomeu Vizoso
On Fri, May 22, 2009 at 14:23, Sascha Silbe
sascha-ml-ui-sugar-de...@silbe.org wrote:
 On Thu, May 21, 2009 at 10:03:09AM +0200, Tomeu Vizoso wrote:

 1) Stop checking out random unstable versions of external projects.
 They break very often, and we cannot fix them.  Let's instead upgrade
 manually every once in a while after some testing.

 We are supposed to be doing this already, [...]

 Are we? The first line of the Jhbuild wiki page still reads:

 Sugar-jhbuild will automatically download the latest of Sugar's
 dependencies as well as Sugar itself directly from their source
 repositories, rather than relying on source packages that may have become
 stale.

That surprises me. At the beginning, we depended on several features
that weren't yet released by the upstream projects. But as of today,
most of it should be released (if not packaged).

I would say that whoever wrote that was misinformed or it's really old info.

 To me, changing this is a policy decision, so I'd like to have a broader
 discussion about it.

 Advantages:
 + less frequent breakages (only on manual updates)
 + maybe less total number of breakages (because some of them might be
 already fixed in the meantime)

 Disadvantages:
 - we discover incompatible upstream changes only after a while when upstream
 is less likely to change it
 - regular manual updates needed
 - need to track security updates and apply them ASAP (already a nightmare
 for xulrunner)


 An option might be to use different modulesets in parallel (latest deps +
 latest Sugar, stable deps + latest Sugar, stable deps + stable Sugar) and
 have BuildBot instances for all of them. That way developers can use a
 reliable system, but we still get notified of upstream breakages early.

I think that what people are asking is for simplifying jhbuild, so I
would go for binary packages when possible, then released tarballs and
then for pre-release tarballs (snapshots). That's for external
dependencies, I think we should checkout the latest sources of all the
packages maintained as part of Sugar.

 We already use distro packages wherever possible, BTW (*). So this is just
 about packages where the distro version (if any) is unsuitable to Sugar,
 usually either because it's an old distro version or we're relying on very
 recent features.


 (*) If you find out that for any package we currently build on our own the
 distro version in fact suffices, please file a bug against sugar-jhbuild. I
 have little to no information about which versions or features we actually
 need.

Cheers,

Tomeu

 CU Sascha

 --
 http://sascha.silbe.org/
 http://www.infra-silbe.de/
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.9 (GNU/Linux)

 iQEcBAEBAgAGBQJKFpkiAAoJELpz82VMF3DaVSwH/3OD4tLVNCZoOogFiY42LQXn
 OGQ6CXgcqDs55SvghmFpTpa6vOXwGn/kUo6Gk4wOqduISoVebHi8mBaM1g3Oq+/d
 SlsNVPoEkEb58xI1sTmSkYNqnleoIcwkuF6XtnK/qadqcu/V/hi3gNWjaKVfT/Ih
 pv1qwg//hkH4jiB7vMPml/12r5KBgiV/64WvqFkS/I9b0tYD49xpJuGV953pKC2K
 GTdTTsoHOKJid4tLl1+6WjiCovCzWpzMF+BlGwMkLiDPwgWkmtmX4qSzVORa4YAe
 rsLV6fUORM6tiiyzjCDFpbmiToJwwVdb9faEYLJI26JOWwFY6p3A2+9TligxrJg=
 =qiD/
 -END PGP SIGNATURE-


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Tracking upstream versions with sugar-jhbuild (was: Re: Simplifying sugar-jhbuild)

2009-05-22 Thread Martin Langhoff
On Fri, May 22, 2009 at 2:30 PM, Tomeu Vizoso to...@sugarlabs.org wrote:
 That surprises me. At the beginning, we depended on several features
 that weren't yet released by the upstream projects. But as of today,
 most of it should be released (if not packaged).

+1

 I think that what people are asking is for simplifying jhbuild, so I

Yes. And generally lowering the barriers of entry to hacking on Sugar.

Sugar (and the whole OLPC stack) used to carry a ton of patches that
made things painful and fragile.

Nowadays, most of those patches found their way upstream. Perhaps it's
time to take advantage of that and simplify things :-)


m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel