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 Sugarfirstname.lastname@example.org http://lists.sugarlabs.org/listinfo/sugar-devel