<br><br><div class="gmail_quote">On Tue, Jun 17, 2008 at 10:29 AM, Frank Murphy <<a href="mailto:frankly3d@gmail.com">frankly3d@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><div class="Ih2E3d"><br>
</div>Maybe reduce rawhide release(s) to weekly and date?<br>
eg: yum-3.2.16-2.fc9.061608.noarch.rpm<br>
<br>
So more testing can be accomplished<br>
<font color="#888888"></font></blockquote><div><br><br>That unfortunately increases the amount of delay before new fixes can be brought in, which is the other side of the coin. The plain problem is that the Fedora package set is /huge/, and I don't think there is any reasonable way we can try to coordinate all the various pieces of it into a cohesive testable unit outside of the major effort that goes into our alpha/beta/prerelease parts, and even that doesn't get the whole thing.<br>
<br>I don't disagree that this is a tough problem, or that there is even a problem here. I just don't know of a good way to solve this problem that doesn't introduce lots of others, such as the above mentioned lag on getting fixes into the hands of the masses.<br>
<br>I've always felt that the alpha/beta/pre releases provide good well known starting points for the Rawhide adventure. You can be reasonably certain that those points will install on your system. From there you can update yourself in part or in whole to Rawhide de jour in order to verify operation of a particular piece of software or subsystem. It is true that bugs contained within the alpha/beta don't really matter much past the rawhide day that these were snapshot from. If the bug persists into the current rawhide version of the given package then it does matter, but there is often a chance that it's been fixed along the way.<br>
<br>Anyway, I'd love to have more of this discussion sometime around FUDCon, and more on list too.<br><br>--<br>Jes <br></div></div><br>