[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Meaning of the "Altering package upload rules"



On Fri, Feb 15, 2008 at 09:42:47AM +0900, Charles Plessy wrote:
> This is a very good idea, but the reason why source-only uploads are not
> allowed is that there are concerns that if the binary package is not
> used for real, the quality of the source package will drop. Within this
> hypothesis, there is no incentive for the laxist developper to use the
> valuable feedback that you propose.

I personally consider this argument bogus as well. Let's imagine we can
split DDs and DMs into "good" and "bad" uploaders. Good uploaders
nowadays use a clean p/cowbuilder environment, test their packages, yada
yada, and then upload. Bad uploaders build in their dirty sid machine
and then upload without testing. Good and bad uploaders exist now with
binary uploads and will exist with source uploads.

The question is how much we think that requiring a deb for the upload is
an incentive for pushing the bar of a random uploader nearer to the
status of good uploader than to the bad one. I think it is indeed an
incentive, but the current drawbacks are far worst than this benefit.

Hence I think we should push for source upload. Other technical
incentives can then be found and I've already suggested some of them,
e.g. tuning our upload tools so that they indeed require the existence
of a .deb, not necessarily uploading it later on.

The idea of actually not throwing away them proposed by Enrico (Tassi)
is indeed nice, but AFAIK our upload infrastructure (that is: not that
in detail) it will require some changes, since the uploaded .deb will
need to be stashed somewhere, as they will clash with .debs having the
very same name which will be generated by the buildd. So I think that
for the moment the idea can be postponed ...

> When he communicated about source-only uploads in his email of January
> 2007, James Troup wrote:
> 
>   "This is not something I personally think is a good idea but
>   I won't stand in the way of consensus of the Release Managers and the
>   developer community as a whole."
> 
> http://lists.debian.org/msgid-search/873b5zaoh4.fsf@pasta.gloaming.local

I'm aware of that mail, and that is why we are stuck with binary
uploads, because a single person do not want to change the rule.

> The other concern of James Troup is that the i386 buildd may not keep
> up. So I guess that another piece of the puzzle is in the hand of the
> i386 buildd maintainers, the release team, the i386 porters, and the
> system administration team.

I'm pretty sure the DPL will be happy to authorize the disbursement of
money to enlarge our i386 buildd park (Cc-ing him to check whether this
is actually the case or not). I'm not volunteering to set up another
i386 buildd though, since right now I don't know where to start. But
even in this respect I'm well convinced that the day we will have source
only upload and overloaded i386 buildd, we will have manpower to set up
some more.

> Then, because "a consensus between the Release Managers and the
> developer community as a whole" has been required, a GR will be needed.
> Since it is a necessary step, the writing of it may be a useful tool to
> clarify arguments before presenting them to the persons in charge ?

Yes, I think it would definitely be *the* step needed to solve this once
and for all, and I think the consensus on allowing source only upload
will also be easy to reach among DDs (but of course I might be wrong).
I've thought several time of drafting such a GR myself, but thus far
I've lacked the actual time to do it ... help in the form of a first
draft would be really appreciated ;)

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ............... now what?
zack@{upsilon.cc,cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?    /\    All one has to do is hit the
(15:57:15)  Bac: no, la demo scema    \/    right keys at the right time

Attachment: signature.asc
Description: Digital signature


Reply to: