On Tue, 2008-06-17 at 10:44 -0400, Jesse Keating wrote: > > > On Tue, Jun 17, 2008 at 10:29 AM, Frank Murphy <frankly3d@xxxxxxxxx> > wrote: > > Maybe reduce rawhide release(s) to weekly and date? > eg: yum-3.2.16-2.fc9.061608.noarch.rpm > > So more testing can be accomplished Rawhide definitely meets the need of providing latest and greatest package content by way of mirroring the yum repo daily. If you find a busted package, report the bug, it gets fixed ... you only have to wait at most 23:59. Talk about a tight feedback loop, that's great! The pain point for me has been integrating the latest and greatest content, while attempting to stabilize components which have significant dependencies (e.g. installation). We typically get stuck in a cycle where a bug blocks installation ... and during the blocked period ... development continues. This isn't a bad thing for development, but can often leads to a perfect storm where: 1) packageX introduces a blocker for installation testing 2) new code lands in anaconda-devel that introduces/exposes a bug 3) packageX bug is fixed 4) packageY introduces a blocker for installation testing 5) new code lands in anaconda-devel ... This tends to be the case between milestones. All engineering energy is focused at removing the blockers, but many more serious issues remain under the covers. I've seen several solutions on the table in the past ... each with their own pros/cons. I'll toss a few that are on my mind now (and please fill in the blanks if there are others) ... 1) Greater visibility on test blockers Perhaps just raising awareness that testing is blocked on a particular component or sub-system is sufficient. 2) dist-f10-anaconda koji tag Continue providing rawhide, but also allow for baking/testing of anaconda related changes in a specific koji tag. This tag would be used to build anaconda install/boot images in order to test anaconda changes and features. The same packages could be either tagged for general rawhide consumption at build time, or after testing has completed. 3) Host several days of rawhide Continue mirroring just 'rawhide' latest ... no change there. However, begin hosting timestamp'd daily copies of rawhide. rawhide -> rawhide-20080604 rawhide-20080604 rawhide-20080603 rawhide-20080602 rawhide-20080601 The idea here being we have a working rawhide for at least several days in order to walk through a test matrix. Jesse: You know the internals of the mirroring, you probably have better insight to say why this isn't done, and perhaps why we don't want this. 4) Make "rawhide" just a yum repo Only partly serious here ... drop the install images from rawhide. Doesn't mean that the rawhide package set cannot be tested during development, only that the boot/install images won't necessarily be built against rawhide. I'm only partly serious here. But what appeals to me about this is it's very clear what we are providing. Just a repo ... do with it what you like. One use case of the repo would be building/hosting install images elsewhere. Another might be liveCD generation. We'd certainly need to work that out install image creation as to not impede community installation testing. Any other thoughts/ideas out there that might help clear up what the intended use for rawhide is? > 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. > > 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. > > 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. > > Anyway, I'd love to have more of this discussion sometime around > FUDCon, and more on list too. Yeah, I'd be up for further discussion @ FUDCon. If nothing else, any discussion might serve to strengthen+support why things are the way they are. Thanks, James > -- > fedora-test-list mailing list > fedora-test-list@xxxxxxxxxx > To unsubscribe: > https://www.redhat.com/mailman/listinfo/fedora-test-list -- ========================================== James Laska -- jlaska@xxxxxxxxxx Quality Engineering -- Red Hat, Inc. ========================================== -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
