[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Do not make gratuitous source uploads just to provoke the buildds!



Op vr, 11-03-2005 te 17:03 -0800, schreef Thomas Bushnell BSG:
> Steve Langasek <vorlon@debian.org> writes:
> 
> > Re-uploading a package to provoke a buildd response is counterproductive,
> > *particularly* when the package is already in Needs-Build on the missing
> > architectures.  Re-uploading doesn't change its position in the queue, but
> > it *does* force buildds for all the other archs to needlessly rebuild the
> > package.  This is why the answer to your previous email was "please be
> > patient".
> 
> Unfortunately, the queue ordering policy is unclear.  I was guessing
> that the priority of the upload would have something to do with
> queueing policy.

As is explained on
<http://www.debian.org/devel/buildd/wanna-build-states>, this is not the
case.

> Since the all but one of the other arch buildd's have empty
> needs-build queues, it is harmless to force them to execute a
> recompile and costs no scarce resources.

If everyone would reason like that, then it will cost scarce resources.
This is a bogus argument.

> I did check this before
> uploading. 
> 
> I made an upload because a related package (grisbi) just seemed to get
> compiled by all the buildd's in a nifty two-day round trip time.

You were lucky that time around, then.

> It
> was uploaded March 10, compiled by most buildds on the 10th, and by
> arm and mipsel on the 11th.  I concluded that the queue must take note
> of priority or something like that.

It does not.

[...]
> If, perhaps, there was a clear indication of the buildd ordering
> policy, then it could be properly used.  Until then, I go on the basis
> of guesswork.  

That indication is there, and it mainly boils down to 'buildd builds
packages in a more or less predefined order which a maintainer has no
direct influence on'. Of course, we can massage the ordering if
required, but that is only done in exceptional cases.

If your problem is 'my package will not migrate to testing!', then you
are wrong, too. There are precedents for release managers forcibly
moving packages to testing, even if the architectures are not in sync;
there are precedents for an architecture with a huge backlog being
temporarily ignored for the testing migration.

In any case, re-uploading to force a package rebuild is /always/ the bad
thing to do.

-- 
         EARTH
     smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
         WATER
 -- with thanks to fortune



Reply to: