On 02/10/2011 12:41 PM, Jonathan G. Underwood wrote:
> On 10/02/11 16:07, Troy Dawson wrote:
>> I believe this upcoming Beta will be our last beta.
>> Using our original guidelines I think we have put in all the features
>> and programs that we intended to.
>>
>> Here is my ruff schedule. Please don't hold me to any of these dates,
>> because in the end "We'll release it when it's ready"
>>
>> Beta 3 - February 11, 2011
>> - updated livecd-tools, liveusb-creator
>> - openafs-firstboot fixed
>> - kdemenu fixed
>> - report fixed.
>>
>> RC 1 - February 18, 2011
>> - All features or programs in release.
>> - All bugs of previous week fixed.
>> - Move all references of 6rolling to 6.0
>>
>> RC 2 - February 25, 2011
>> - All bugs of previous week fixed.
>> - Documentation
>>
>> RC 2.5 - Sometime in the first week of March, 2011
>> - This is really the release, down to the documentation.
>> - If there is no further bugs, RC 2.5 images are declared the official
>> release images.
>> - If there is a show stopping bug, we will have a RC 2.75
>>
>> Release - A day or two after RC 2.5 - Hopefully in the first week of March.
>
> Is there a recommended method for installing a beta (from the 6rolling
> tree) and updating packages throughout this process such that the
> machine ends up with the 6.0 release?
>

For production systems, we are recommending that you do a fresh install 
after the final release.

For machines you don't care about as much.  Yum will update you to the 
final release.

> I know how this is handled for Fedora, but I guess what I'm not clear on
> is whether SL is updating package EVRs with each package rebuild (which
> would mean a simple yum update follows the development), or keeping them
> identical to TUV shipped packages and over-writing (which yum wouldn't
> notice)?
>

We are done with that phase.  While we were in the Alpha stage TUV 
packages changed without being renamed.  All of our SL packages, which 
is what we are working on during the Beta phase, will have their release 
numbers increase so that yum is able to update to the latest.  So you 
shouldn't have to worry about that.

> Also, while installed systems using the SL packaged yum repo definitions
> will seemlessly move from the 6rolling to the 6 tree as the repo
> packages are updated, this isn't the case for machines deployed from
> cobbler without manual intervention at the right point on the cobbler
> server, as the cobbler OS repo location is manually specified. What
> might help here is if there was a 6 link pointing to 6rolling through
> the beta and RC phase. Is that possible?
>

I'm not quite sure what you mean by the link.
But the 6rolling area will have the same packages as the 6.0 area.  The 
6rolling won't just sit at Beta or one of the release candidates.
As we move out the release candidates, we move everything from our build 
area, to the rolling area, test there, and then move it over to the 6.0 
area, and test again.  So at the release candidate, and release phase, 
6.0 and 6rolling will be the same.
Or is there something else that would make cobbler happier?

Troy
-- 
__________________________________________________
Troy Dawson  [log in to unmask]  (630)840-6468
Fermilab  ComputingDivision/SCF/FEF/SLSMS Group
__________________________________________________