Re: Discarding uploaded binary packages
2012/10/21 Charles Plessy <firstname.lastname@example.org>
Le Sat, Oct 20, 2012 at 06:29:50PM +0200, Bernhard R. Link a écrit :
> * Chow Loong Jin <email@example.com
> [121020 18:10]:
> > The only argument I have seen for binary uploads is to ensure that DDs have
> > built the package prior to uploading it. But as someone else pointed out earlier
> > in the thread, we seem to be trusting DDs a lot in other aspects, so why not
> > trust that they test-build packages prior to uploading them as well?
> Having the binary file around, even if it is not easily accessibleIn the end, it is not so relevant that a local build could work on the DD's
> on some remote archive, noone can claim "I tested this, it just did
> work here, something must be different on the buildds" and hope to
> get away with it.
machine. With source uploads, we will switch from a model where most of the
packages that our users install were built and tested by hand, to a model where
most pakcages were autobuilt.
True, but we should also trust that a DD has made at least a binary build and minimal testing on package. If not the case, does he still worth being a DD?
But I really like the idea of sending a binary build that is dropped by the build system. It would avoid sending "accidently" (or not) a package that does not build at all and uses resources (servers, ...) effortless.
In that model, it will be important that after the build, one developer
downloads the binary packages and tests them. The 10 days of staging in
Unstable do not offer much protection when packages have a small number of
users who are not upgrading their system every week.
In that context, it would be helpful to have an email notification after the
packcages are autobuilt on amd64.
For command-line programs, regression tests with autopkgtest will also
be instrumental in helping developers to ensure that binary packages
are functional. (http://dep.debian.net/deps/dep8/)
Have a nice Sunday,
Tsurumi, Kanagawa, Japan
Archive: [🔎] 20121021004724.GB23211@falafel.plessy.net" target="_blank">http://lists.debian.org/[🔎] 20121021004724.GB23211@falafel.plessy.net
gpg key id: 4096R/326D8438 (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438