Re: throw away debs and source only uploads
Le Wed, Mar 30, 2011 at 04:18:34PM +0200, Stefano Zacchiroli a écrit :
>
> Regarding source only upload, well, it's tricky. There is the usual
> tension about the principle desire of trusting every DD to do the right
> thing and the reality-check observation that enabling people to upload
> only sources *will* mean that some people will upload packages without
> having even built them once
Hi Stefano,
I think that one important factor is how often such errors will happen. We can
imagine all sorts of scenarios and devise counter-mesures against them, but are
they all worth the effort, and worth the damage as well ? Because it is always
frustrating to read top-down comments about simple Debian developers to be
sloppy and untrustable. Let's not make it a common assumption.
In what I have seen in the packaging teams that I follow, often when a package
fails to build on all architectures, it is because the developer has not tested
them in a minimal build environment. Making sure that binary packages have been
built together with the source package is not solving that problem.
On the binary side as well, what the maintainer can do to test the packages by
hand is also limited, not to mention that testing more than one architecture is
time consuming (so I usually never do). Build-time regression tests and
facilities to let users run the same tests on the binary packages they
downloaded (DEP8 ?) will altogether do much more for the quality of Debian than
using the presence of binary packages accompaniying the source upload as an
evidence of significant qualitative difference compared to a source-only upload.
Asking developers to publish their build logs is far more interesting, and in
the short term, does not require any infrastructure change. Currently, I store
my build logs in the git repositories where my source packages are managed, and
in the case of subversion packages, I send the logs on the maintainer mailing
list. If the uploaded package turns out to be problematic, we have a starting
point for troubleshooting.
And when developers repeatedly commit the same mistake, refuse to realise the
damage they do, and persist in ignoring the solution to the problems they
cause, let'se withdraw the trust we gave them. But does that happen that
often ? My experience is that people learn and improve their skills, not the
reverse. In that sense, occasional failures to build, while not a goal by
themselves, are an inevitable byproduct of increasing our workforce. Automated
reporting of build failures can circumvent the nuisance to the package
maintainers themselves.
Cheers,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
Reply to: