Rawhide stability

[Jesse Keating]

On Wednesday 21 February 2007 16:08, Andrew Overholt wrote:
> For example, how do we expect users to help out with testing if rawhide
> is regularly in a completely unusable state?  Is there something we can
> do to drive towards more continuous stability?  Is this even possible?
> Should we instead focus on making more frequent (weekly?) releases in
> between actual test releases?  Are better tools (such as a better bug
> tracking system, a better delivery mechanism, more effective
> communication media, a better means of working with different upstream
> projects, etc.) the answer to more stability?  Can we achieve stability
> while still pushing the latest technology?  Am I completely nuts for
> attempting to draw any comparisons between Eclipse and Fedora?
>
> I look forward to people's thoughts on these issues.

The biggest problems are almost always broken deps.  That's just the nature of 
things, different parts get built at different times, and a cron job just 
pushes whatever mess is currently there out.  There was talk of doing 
recursive depsolving and removing parts of the push that would break deps, 
but then what lands in rawhide isn't the same as what is in the buildroots, 
plus somethings may never go out and see the light of day if we do this.  Not 
to mention compose time would skyrocket :/

-- 
Jesse Keating
Release Engineer: Fedora
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-maintainers/attachments/20070221/2650c200/attachment.sig>