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?

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)?

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?

Cheers,
Jonathan (new to following SL development).