"Joe Smith" <[EMAIL PROTECTED]> writes:
> "Pierre Habouzit" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
>>Human error, or poluted chroot/compilation env is more likely to happen
>>on the developper machine than in a buildd. Maybe this has already been
Also for each upload we have 10 archs with the risk of buildd polluted
packages and one without? How does that help at all?
You reduce one risk by eliminating it from <10% of the uploads and
introduce a completly new and different risk on those 10%. No matter
how you look at it that is just silly.
>>discussed once, but I think that binary uploaded packages (except the
>>binary NMU's which are quite an exception) should be tagged as
>>"uploaded" (in opposition with "build by buildd" aka "built"), and
>>should be queued in the buildd's with a very low prioirity so that it
>>won't hurt the current flow of packages, but would detect some FTBFS
>>early.
>
> I planned to offer a very similar proposal.
> My suggestion was to allow Source-only, but have it revokable per-user
> to cover cases of abuse (developer keeps uploading broken packages,
> especially if they are libraries).
> Have the prefered method of upload be source+1 uploaded binary. The
> uploaded build ensures that the package is available immediately (for
> at least one arch).
> all uploaded binaries would be placed in the buildd queue at a very
> low priority, probably the lowest priority. This would ensure that the
> backage does build correctly on a clean system. IFF the build on the
> buildd succedes the binary package coukl perhaps be replaced with the
> one from the buildd. (This is likely one of the more controversial
> points, so I leave it up to discussion should anybody even consider
> implementing this.)
If you replace the debs then the uploaded changes file (which gets
send out to the ML and is the only one publicaly archived by debian)
don't match the debs in the archive.
If you want to go the way of rebuilding debs then require seperate
changes files.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
