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/[EMAIL PROTECTED] 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? [EMAIL PROTECTED],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
signature.asc
Description: Digital signature
