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.
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.