On Tue, Aug 19, 2003 at 09:16:03AM +0100, Andrew Suffield wrote:
> On Mon, Aug 18, 2003 at 10:38:10PM -0600, Joel Baker wrote:
> >
> > 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.
Just like the current system, which requires that uploads be made for all
architectures that previously appeared, yes. Funny that.
> > No, in fact, it doesn't. Which is the crux of the question.
>
> Argument by repeated assertion.
Back at you. Which would imply that the entire issue can be resolved by
demonstrating which of the two assertions is, in fact, correct.
> > Are you attempting to suggest that the buildd arrangement uploads broken
> > packages more often than maintainers do?
>
> Probably about as frequently.
Okay; we're clear on that assertion, then.
> > No, you can't. Or rather, you can swap it, and the wording is equally
> > parseable - but no longer accurate. See above.
>
> And again.
Which reduces to the same question. Fine.
> > > 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.
Agreed, but probably not in the way that you think. I'm going to assert
that keeping things sane on a few dozen machines (the buildds) is easier
than keeping them sane on 1000+ (assuming each developer has at least one
machine to develop on; I have 3, myself).
I suspect that's not the assertion you're trying to make, but it comes
down, again, to a question of which assertion is *correct*.
> > 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?
Because they have folks who spend a lot of time trying to ensure that
they *are* better, for one; for another, the design of the buildd setup
guarantees that, barring a very significant bug, it *will* catch one of
the primary forms of maintainer error, which was the origional point -
that fewer packages would be broken *because of* going through a buildd
than would be caught as broken by going through a buildd.
But let us take one concrete example: webmin. Which, as the bug filed and
the conversation on the list should indicate, would probably have been
caught by the proposed change.
Feel free to document at least one case of a situation where a buildd would
have caused an otherwise-proper upload to become a bad upload, by replacing
the maintainer's binary-indep results with those from the buildd.
--
Joel Baker <fenton@debian.org> ,''`.
Debian GNU NetBSD/i386 porter : :' :
`. `'
`-
Attachment:
pgpWXWzEF0rdI.pgp
Description: PGP signature