Re: [Sugar-devel] Tracking upstream versions with sugar-jhbuild (was: Re: Simplifying sugar-jhbuild)
On Fri, May 22, 2009 at 2:30 PM, Tomeu Vizoso 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
Re: [Sugar-devel] Tracking upstream versions with sugar-jhbuild (was: Re: Simplifying sugar-jhbuild)
On Fri, May 22, 2009 at 14:23, Sascha Silbe 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
[Sugar-devel] Tracking upstream versions with sugar-jhbuild (was: Re: Simplifying sugar-jhbuild)
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
