Bug 140142

Summary: create stable rolling rawhide-style repo
Product: [Fedora] Fedora Reporter: Phil Schaffner <philip.r.schaffner>
Component: distributionAssignee: Bill Nottingham <notting>
Status: CLOSED WONTFIX QA Contact: Bill Nottingham <notting>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: katzj, rvokal, sopwith
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-11-22 04:46:20 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Phil Schaffner 2004-11-20 04:52:32 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20041020

Description of problem:
Create a rawhide-style rolling repo, but with stable/tested packages
that could be used for either anaconda installs/updates, or yum
updates.  Would save user download/install/update time and network
bandwidth.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Do network or ISO install
2. Do updates
3.
    

Actual Results:  Inefficient process.

Expected Results:  Single install/update process that gives latest
stable packages.


Additional info:

Thanks to David Fletcher for stimulating the thought.

Comment 1 Bill Nottingham 2004-11-22 04:46:20 UTC
A rolling release w/ISOs would eat up a lot of bandwidth and disk
space, aside from the release engineering and testing efforts involved.

Comment 2 Phil Schaffner 2004-11-22 17:38:05 UTC
Thought the extra effort might be problematic, but just to be clear,
was not suggesting new ISOs.  Know that doing more regular ISO respins
has already been discussed and rejected.  Figured the same process
used for rawhide/development updates would work here, just limiting it
to stable packages.

Comment 3 Bill Nottingham 2004-11-22 17:41:51 UTC
The main concern I have is that none of the packages are tested in an
install environment, and there wouldn't be any automatic testing of
such trees.