On Mon, Aug 18, 2003 at 10:38:10PM -0600, Joel Baker wrote: > On Tue, Aug 19, 2003 at 12:55:06AM +0100, Andrew Suffield wrote: > > On Mon, Aug 18, 2003 at 02:21:55PM -0600, Joel Baker wrote: > > > > This is based on the assumption that a given buildd has a better > > > > chance of being "valid" than the maintainer's workstation. I see no > > > > reason to believe that. > > > > > > No, it is based on the assumption that a buildd will only install things > > > listed in the Build-Depends, which means it will catch stuff that only > > > builds on the maintainers workstation because they aren't building > > > inside a chroot and are being sloppy - one of the main things they catch > > > for binary-arch targets, today. > > > > People seem to be doing quite well enough at catching those > > already. As you're so fond of saying, if they weren't then we wouldn't > > be having this conversation (note how meaningless that is?). > > Primarily because a few individuals appear to be doing, on their own time > and bandwidth, exactly what I propose - that is, invoking the binary-indep > target on a building machine other than the maintainer's. > > If they get hit by a bus, reassigned by their job to Outer Mongolia, or > just plain get bored with doing it, we lose that benefit entirely, as > things stand today. I'm proposing that the function appears to be producing > clear benefits, and that we should, in fact, adjust our expectations so > that we retain those benefits in a more direct fashion. No, you are proposing something else entirely: that we require somebody like this to upload the binary-indep components before the packages enter testing. > > > In fact, the buildd is presumed to be valid - must be - because we're > > > using it for every architecture not uploaded. Invalid buildds are, as > > > far as I have observed, caught fairly rapidly, and taken out of the pool > > > until fixed (barring toolchain failures which only affect a few > > > packages, or the like). > > > > Same thing applies to maintainer workstations. > > No, in fact, it doesn't. Which is the crux of the question. Argument by repeated assertion. > > > A maintainer's workstation cannot be presumed to be valid, because we > > > regularly demonstrate that this isn't the case. If we could presume it > > > was valid, we wouldn't be having this conversation at all. > > > > Strange, I thought we actually managed to upload working packages most > > of the time. Are you attempting to suggest that we don't? > > Are you attempting to suggest that the buildd arrangement uploads broken > packages more often than maintainers do? Probably about as frequently. > > > If you think the buildds are invalid, perhaps you should take the matter up > > > with the people running them, and so they can try to fix whatever problems > > > you are seeing? > > > > Right back at you. You can swap "maintainer workstation" and "buildd" > > in your last mail and still have it about as meaningful, which should > > be a hint that you're pursuing a blind alley. > > No, you can't. Or rather, you can swap it, and the wording is equally > parseable - but no longer accurate. See above. And again. > > Note that it is much _more_ important for a maintainer workstation > > (where all the actually important stuff happens) to be working than it > > is for a buildd (which is largely automated, and thusly can be easily > > duplicated, replaced, or re-done). > > Where a failed workstation means someone else can build it, upload it, > do an NMU; hell, you could even use the Debian machine farm (unless > the workstation is your only access at all, which is quite a different > question). Oh hey, just the same as a failed buildd, then. Except that one of these things is easy, and one is not. > If you're going to assert that the buildds are breaking packages, please > provide some backing to the assertion; showing that maintainers break > packages is a trivial excercise in reading the BTS. So is showing that buildds break packages. Although a number of those issues don't go through the BTS. They're probably about as reliable as some random maintainer workstation - which makes sense, why should they be any better? -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- |
Attachment:
pgpUE1Qp7dagp.pgp
Description: PGP signature