On Sat, May 21, 2016 at 02:07:53PM +0800, Paul Wise wrote: > On Fri, May 20, 2016 at 1:34 PM, Vincent Bernat wrote: > > > Totally agree. Our standards are far too high for many upstreams. > > I don't understand the disconnect here. Are upstreams not interested > in software quality to the extent we are? I don't think it's that upstreams aren't interested in quality, but that Debian and (some) upstreams have different opinions on what aspects of quality are more important. * Debian: don't embed copies of libraries you use. It makes it harder to do security updates in the libraries, makes it harder to use the libraries on their own, and makes the Debian package archive unnecessarily larger. Some upstreams: we embed copies of libraries. It makes it easier to install our software, and guarantees us that the library doesn't change from underneath us, and that means we don't need to support many versions of the library. We're an active project, and if a library needs a security update, we do it quickly. * Debian: it's important to follow Debian Policy and the Debian workflow of uploading to unstable and letting packages flow from there to testing and stable, if they don't have bad bugs. There's thousands of people making packages and things will break if they all do the same thing differently. Some upstreams: it's OK to cut some corners and do things simply. We care about getting the software into the hands of its users as soon as possible, and we also don't have a lot of time to spend on packaging. From our point of view, packaging is a necessary evil that is much too difficult and takes much too much time from us. That's effort we could spend on making the software better instead. * Debian: it's important to have package versions that can be supported for many years. We produce a release every two years, and support it for at least three, and more if one counts the LTS project. Software that changes a lot, or that has an API that changes a lot, or that doesn't separate security updates and backport those to the version included in a Debian release, make this harder for us. We can't generally update to a new upstream release whenever there is a security problem, as it would negate the point of making Debian releases. For example, the new upstream version might require entirely new forests of dependencies, or newer versions of dependencies, all the way down to the kernel. For some packages that we deem sufficiently important to our users, we deal with that, but it is not something that generalises to all packages. Some upstreams: we don't support our old releases. We have only so much time to spend on this software, and supporting old releases would take a lot of effort we don't have time for. That's why we embed most of our dependencies into the installation packages we make, so that they can be installed onto the Debian releases, even if we decide to require more dependencies, or newer versions of them. Et cetera. Debian has one set of quality factors it particularly cares about, and some upstreams think differently. -- Schrödinger's backup hypothesis: the condition of any backup is undefined until a restore is attempted. -- andrewsh
Attachment:
signature.asc
Description: PGP signature