Official presto repositories for Rawhide

[Jeremy Katz]

On Tue, 2007-06-19 at 15:29 -0500, Clark Williams wrote:
> Jeremy Katz wrote:
> > On Tue, 2007-06-19 at 00:40 +0200, Axel Thimm wrote:
> >> On Mon, Jun 18, 2007 at 06:11:47PM -0400, Jeremy Katz wrote:
> >>> The question is where in the process does it make sense to generate
> >>> the deltas.  Do we do them in the build system (the koji level)?  Do
> >>> we do them in the update system?[1] Do we do them at tree compose
> >>> (mash) time?  Each has tradeoffs... not sure which is really the
> >>> best.
> >> The problme domain are the limited bandwidth of end users, so you want
> >> it to run on what end users consume. This can be different for
> >> released versions vs rawhide, but in general released versions would
> >> only perform this on updates-released (not updates-testing) and
> >> for rawhide on everything.
> > 
> > Yeah, it's easy to see that deltas for -updates and -updates-testing[1]
> > from the release and probably the last update make sense[2].  rawhide is
> > definitely the trickier to figure out where to draw the line.
> 
> Do you even want to draw that line in rawhide? To me, rawhide is
> dangerous enough that trying to add delta updates on top of it is just
> asking for (more) trouble.
> 
> I think that -updates* is perfect for deltas, because the latest package
> is almost always going to be an iteration on the previous version(s).
> But rawhide might be a complete version jump, or changing toolchains, or
> trying something just plain whacky. The potential for space saving due
> to commonality doesn't seem to be there for rawhide.

The space savings benefit isn't really the win for rawhide -- it's more
the testing base and being able to ensure that things continue to work.
Because nothing sucks more than doing a release and then realizing that
some part doesn't work because it's not a regular part of your devel
infrastructure.

Jeremy