NascentUpload doesn't look in the NEW queue

Bug #3138 reported by Daniel Silverstone on 2005-10-14
Affects Status Importance Assigned to Milestone
Launchpad itself

Bug Description

When looking for a source package we currently don't check the NEW queue. This means that may reject a binary build when we could in theory accept it and attach it to the upload in the queue.

Changed in launchpad-upload-and-queue:
assignee: nobody → dsilvers
Daniel Silverstone (dsilvers) wrote :

In principle this is also needed for checking against queue/accepted.

Also we need to consider making queue entries depend on others because otherwise we combine the queue entries and end up with a bizarre accept message. especially coming out of NEW

Celso Providelo (cprov) wrote :

Currently we check correspondent PUBLISHED | PENDING publishing records and additionaly check the ACCEPTED queue. Is it really necessary to check NEW ?

Because we may validade some upload counting on a possible acceptation of the NEW source, which is kind of wasting time, since it's never going to happen in normal workflow, only in external binary upload.

Changed in launchpad-upload-and-queue:
assignee: dsilvers → cprov
status: Unconfirmed → Needs Info
Celso Providelo (cprov) wrote :

So, as personally discussed, check in NEW isn't required right now. All the code we need is in Soyuz Mainline (r 3283)

Changed in launchpad-upload-and-queue:
status: Needs Info → Fix Committed
Celso Providelo (cprov) wrote :

Build from NEW was postponed, since it cn be considered obsolete if we reduce the turnaround time in Soyuz from less the 1/2 hour (currently 1 hour)

Changed in qprocd:
status: Fix Committed → Fix Released

The code XXX in nascentupload is still there for this.

Although there's no need with current policy to check against sources in the NEW queue when looking for the source package matching an uploaded binary, we should do this anyway - nascentupload should work for anything which makes sense, not just the subset our policy currently allows.

Changed in qprocd:
assignee: cprov → nobody
importance: Medium → Low
status: Fix Released → Confirmed
Celso Providelo (cprov) wrote :

In fact, bug #31038 fix introduces a new approach:

uploads present in NEW are considered untrusted, they can be duplicated (same name/version) and the uniqueness will be only enforced in the transition to ACCEPTED.

Since *known* uploads are promoted to ACCEPTED automatically in the upload time (auto-approve), they will be rejected if the uniqueness is not respected.

So, we definately don't want to check version consistency against NEW.

Maybe storing possibly duplicated NEW uploads will let us in a risk condition, by wasting storage space and other resources, but I don't think this is the case right now.

William Grant (wgrant) on 2011-05-30
visibility: private → public
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers