Re: 2013 sometimes still feels like 2003 or 1993 (Re: NEW processing during freezes
On Fri, May 03, 2013 at 04:38:40PM +0200, Josselin Mouette wrote:
> Le vendredi 03 mai 2013 à 09:18 +0800, Chow Loong Jin a écrit :
> > While we're at it, can we also have source-only uploads? Uploading potentially
> > huge binary packages that just go to /dev/null seems like a pointless waste of
> > bandwidth to me, and the only for argument I've heard (which I don't buy) is "so
> > that we know maintainers have test-built their packages."
>
> There is a solution to both the upload bandwidth problem and the the
> problem that buildd binaries are untested, but I???m afraid it implies
> changes to dak.
>
> This means configuring dak to accepting only two types of uploads:
> - source-only uploads
> They are pushed to the buildds, and the produced binaries
> (including arch:all) are put in a staging area (much like
> incoming.d.o). These binaries can be downloaded, but
> the .changes cannot (to forbid skipping the second step).
> - binary-changes-only uploads, without binaries
> The developer uploads a sole .changes referencing the set of
> binaries he has downloaded (and tested, although it is hard to
> force that step). Anything referencing binaries not built on the
> buildds is ditched.
>
> This way, you ensure that the actual binaries ending up in the archive
> have been tested, which is neither the case with just source-only
> uploads (no binaries tested) nor with ditched-binary uploads (the binary
> might be built in a different environment).
>
> Cheers,
Firstly: We already know we can't trust all maintainers to build
binaries in a clean chroot. Nor can we trust them to test binaries
they upload. What makes you think maintainers will not simply blindly
create changes files for buildd build binaries and upload them?
Secondly: Maintainers will only test binaries for their own arch. Most
archs won't get this extra test step so most uploaded debs will still
remain untested.
Overall it seems like that extra step will just create extra work for
the maintainer at a time (hours, days, weeks after the upload) not of
his choosing with little benefit to the user.
Those maintainers that do properly test stuff will test the packages
before doing the source only upload. And I have enough confidence in
the autobuilders to produce working debs from a well tested source.
It's not 100% but close enough. The rest will be cought in unstable
quickly enough.
Those maintainers that skip or even circumvent testing will always do
so. And I would rather have buildd build debs there than whatever
those maintainer manage to hack together to produce a deb. I've seen
uploads with debs where the source had a make error in debian/rules.
There is no way that source package could ever have produced the
uploaded deb. At least those kind of errors would be eliminated.
MfG
Goswin
Reply to: