separate binary NEW entries for each architecture

In fact, they are, each individual architecture specific build come from slave as a single buildd upload, corresponding to a single build_record (remember the key distroarchrelease).

Perhaps, they are meant to be already ACCEPTED (known binaries), but it's a different problem.

Give me more info about what make you think this is a bug.

On Mon, Mar 06, 2006 at 06:36:37PM -0000, Celso Providelo wrote:
> In fact, they are, each individual architecture specific build come
> from slave as a single buildd upload, corresponding to a single
> build_record (remember the key distroarchrelease).

(As a distro admin, I don't really care about the details of the
database backend, and generally I don't think I should have to. queue
should be able to hide details that don't matter.)

> Perhaps, they are meant to be already ACCEPTED (known binaries), but
> it's a different problem.
>
> Give me more info about what make you think this is a bug.

They should show up as a single aggregated record in queue, and I should
be able to override them all at once. At present, if three architectures
have built binaries when I process NEW, then the NEW approval will only
apply to those three builds, and when the other three build the binaries
then they'll show up in NEW again, which creates extra unnecessary work
for me.

katie didn't have this misfeature; once I did NEW processing for a given
binary then it applied to later builds of the same binary on other
architectures.

Colin Watson wrote:

[snip]

> (As a distro admin, I don't really care about the details of the
> database backend, and generally I don't think I should have to. queue
> should be able to hide details that don't matter.)

It's relative, bad drivers assume the same concept, they "don't really care"
about the essential details, we know the result.
Anyway, let's discuss at the required abstraction level.

[snip]

> They should show up as a single aggregated record in queue, and I should
> be able to override them all at once. At present, if three architectures
> have built binaries when I process NEW, then the NEW approval will only
> apply to those three builds, and when the other three build the binaries
> then they'll show up in NEW again, which creates extra unnecessary work
> for me.

It follows the initial specification that don't assume we have the same
overrides across architectures. if you say we should assume that, I can
implement this in the 'find_and_apply_overrides' method ASAP.

> katie didn't have this misfeature; once I did NEW processing for a given
> binary then it applied to later builds of the same binary on other
> architectures.

Right, I'll save my commendations about Katie ;)

--
Celso Providelo <email address hidden>
Canonical Ltd - http://www.canonical.com

So this is a bit of a trade-off. Apparently dak actually now permits different overrides for different architectures. There are some corner cases where this is useful, generally around priorities: for example, hfsutils should strictly be Priority: standard on powerpc, where HFS filesystems are common, but Priority: extra on other architectures. We have a consistency-check script that's been warning about that particular inconsistency and a couple of other similar ones for some years now ...

That said, I don't think this should influence the design of NEW queue handling, because there are a handful of cases like this in the whole archive and they rarely change. I think my recommendation would be, if it's possible, to assume that the same overrides should be applied across all architectures when they're going through the NEW queue, but to permit single architectures to be overridden later using change-override.py. If that is impossible, then it wouldn't be the end of the world to just assume that overrides will always be the same on all architectures.

That said, NEW queue handling is much less of an issue nowadays in practice; the bulk of it is scripted.