[1] If your primary focus is main, you may be tempted to say "oh, they're
     in universe, so they don't matter very much".

     Firstly, the noise causes a problem in itself; many Launchpad bug
     views don't make it particularly easy to see what component bugs
     affect, and we often have to filter things out in order to do
     release management effectively.

     Secondly, we often have to promote packages from universe or fix
     problems in universe in order to meet user/customer demand or clean
     up various bits of the archive, so allowing universe buildability to
     be a swamp causes us velocity problems.

     Thirdly, we provide universe for the benefit of our users; even if
     Canonical engineers generally have main as their primary focus, we
     all lose out if our users are having upgrade problems due to a
     popular package in universe failing to build and so being stuck on
     an old version of a library that conflicts with other newer
     packages, or something like that. [2]

Fourthly, for armel at least, fixing toolchain related build failures (quite a few and usually gcc regressions) in universe helps make the tools better and can translate to similar fixes in main. This is less of an issues on x86/amd64 where the toolchain is more mature and better tested in general.

Jani



--
ubuntu-devel mailing list
[email protected]
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Reply via email to