On Mon, Mar 28, 2011 at 03:37:05PM +0100, Mark Hymers wrote:
> Ok, the situation here is the following:
Thanks a lot for taking the time of clarifying.
> The main decision which needs to be made is whether, as a project, we
> want source only uploads or to throw away DD built non-all debs.
> There's not entire agreement amongst the ftpmasters about this (I err
> on the side of the source-only uploads to avoid making people waste
> time and bandwidth but that's not the only opinion).
<snip>
> Once a decision is made, implementation is easy, but I'd like some
> form of consensus before we go down that route.
So, let me see if I can help out in shaping the discussion around this.
First of all my gut feeling is the same as Don's [1]. I've the
impression that throw away debs is a rather uncontroversial step to take
and that we could take independently from source only uploads.
[1] http://lists.debian.org/debian-devel/2011/03/msg01063.html
Clearly that would not solve some of the issues that source only uploads
would solve, most notably the "wasted bandwidth" issue. At the same
time: 1) it won't be worse than the status quo in that respect either,
and 2) would be better than the status quo in terms of package
uniformity wrt their build environments.
I saw only one potential drawback in going forward with throw away debs,
namely the risk of doing some job to implement them and them throw it
away the day, potentially near, we further switch to source only
uploads. My interpretation of your mail is that this risk is pretty low,
as the involved work is low as well. (Yes, I've also seen the various
interesting proposals of comparing metadata of uploaded packages against
those of rebuilt packages and I understand that implementing those would
require significantly more work. But none of those proposals seem to be
*requirements* to go ahead.)
If my gut feeling will be shown to be wrong on the consensus around
throw away debs (with evidence coming as angry replies to this mail), I
propose to have a poll on throw away debs.
Bottom line #1: I propose to go ahead and deploy throw away debs, as
soon as technically feasible.
--------
> One objection to source-only is the perception that people will throw
> untested things at the buildds and see what sticks. That strikes me
> as a social problem, but as a project we probably want to think how to
> handle it.
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; let's call this latter problem "developer
sloppiness". (Shameless [academic] plug: developer sloppiness is fairly
common all over computer science. That's part of the reason why we have
developed over time programming languages which are more and more strict
in *forcing* developers to do the right™ thing, at least by default.)
The main use case I've seen mentioned on list to favor source only
uploads over throw away debs is that of "low bandwidth" or "bandwidth
limits". Most likely, that use case applies to very few people and the
vast majority of uploads could happen without suffering of those
problems.
To address developer sloppiness, sane defaults could be enough. If this
is the case, a solution that might work is a scheme in which source only
uploads are disallowed by default, but at the same time can be enabled
if the uploader really needs to. If the needed explicit step to have a
source only upload gets through is "costly" enough, sloppy developers
won't implement it (after all they are sloppy, aren't they?) and we
should be able to avoid a good deal of gratuitous additional FTBFS.
An implementation which might cut the deal can rely on lintian. We might
for instance have a lintian error which is triggered by a changes file
missing .deb files and have such an error be valid ground for automatic
rejection by dak. A maintainer who really needs to do a source only
upload for that package will simply have to add the proper override.
Bonus features: maintainers which rely "too much" on source only uploads
(assuming that can be defined...) can be easily spotted as the overrides
are in the archive. Drawback of this solution: overrides will be per
package and will have the tendency of stick around packages; that should
not be a big deal either, assuming the current defaults and recommended
practices of dpkg-buildpackage & friend will still be about building
binary packages by default.
The above is just an idea, little more than a brain-dump, for finding a
compromise among the real needs of people with bandwidth problem and the
social issues revolving around developer sloppiness.
Once more: it's material for discussion which IMHO should not be in the
way of the implementation of the throw away debs scheme.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela .......| ..: |.......... -- C. Adams
Attachment:
signature.asc
Description: Digital signature