Just an idea

[Jeff Spaleta]

On 6/2/05, Paul <paul at all-the-johnsons.co.uk> wrote:
> Hi,
> 
> Any way of knowing what is in the next days build? 

no.. there is absolutely no way to for sure to read the future. 
Unless of course you mean.. 3 minutes into the future. If there was a
sure way to know several hours ahead of time what was going to be
built in time for the push to rawhide... we'd always have the
clustering modules in sync with kernels. We already know from list
archive discussion that the clustering modules package maintainer has
a script to watch for new kernel builds...but it doesn't always catch
late-breaking kernel builds in time to make sure the cluster modules
are built for that kernel.

> Reason I'm asking is
> I know new versions of OOo are due as well as other bits and pieces and
> it would be quite nice to know what's in the next days build. 

It's nice to know what I'm getting for christmas the day before too.
Makes it very easy for me to prepare my mock 'I'm so happy you got me
a wallet' face

> also cut down on traffic with people saying "xyz" requires "abc".

The build reports we get now.. don't help with this.. they don't
detail the dependancies. There is no way knowing a day ahead which
packages are going to be in the tree will catch all possible dep
problems, unless you are also told exactly which deps each package
has.
And trust me.. you don't want to get a flat file listing of all deps
to review.

What would help, assuming people are reading the build reports... is
if the build reports also included some output of repoclosure from
yum-utils.  This should give everyone reading the build reports a
headsup of which packages have some sort of dep problem.  Though I'm
not sure how many people are actually reading the build reports.

-jef