What is rawhide for?

Tue Jun 17 17:31:37 UTC 2008

On Tue, 2008-06-17 at 10:44 -0400, Jesse Keating wrote:
> 
> 
> On Tue, Jun 17, 2008 at 10:29 AM, Frank Murphy <frankly3d at gmail.com>
> 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 at redhat.com
> To unsubscribe: 
> https://www.redhat.com/mailman/listinfo/fedora-test-list
-- 
==========================================
 James Laska         -- jlaska at redhat.com
 Quality Engineering -- Red Hat, Inc.
==========================================