On Wed, Jul 18, 2012 at 8:34 AM, Karanbir Singh <[log in to unmask]> wrote:
> Hi,
>
> On 07/11/2012 03:44 AM, Nico Kadel-Garcia wrote:
>> I'm perhaps being unclear, An announcemenbt that goes out at the same
>> time as the release itself is not helpful. They've selected as a
>
> Mirrors know about the upcoming release well in advance - remember that
> we seed in excess of 1200 external non .centos.org mirrors before a
> release. We, CentOS, 'announce' when users can do a yum update. If you
> follow any of the routes where upcoming release work is being
> documented, you would have known about the upcoming release well in advance.

Hi, Karanbir! Interesting to see you over here. For SL users, Karanbir
is the active CentOS team member who does the most effective email
support on their mailing lists, among his other fine qualities, and
I've actually regretted not seeing his interesting and informative
material since leaving the CentOS mailing list.

Karanbir, some of the problems were  the downstreams who run
unofficial mirrors, and the sudden bandwidth hit for folks who run
regular updates. Our favorite upstream vendors make *general*
announcements of when pending releases might occur so we can schedule
resources.

In this case, I certainly believe you that the official upstream
mirrors knew. My unofficial local mirrors, which I use for "mock" and
local virtualization software builds, exploded before I could
pre-populate it and add specific exclusions to trim its size.
(Excluding 6.3 "i386" components, for example.).

>> matter of policy not to announce pending releases: it drove me nuts,
>> and and is one of the contributing reasons to my switch to Scientific
>> Linux.
>
>> Scientific Linux's very effective "rolling" updates for components,
>> before a new release is published, has  been very, very helpful to me
>> in my personal research work building new packages. I'm not doing a
>> panicky, unplanned rebuild of my packages for what is an unplanned and
>> unexpected release with hundreds of updated components: I can keep my
>> testing environments up to date before the release.
>
> So, run a staged local repo, and dont deploy from upstream to production
> on the fly. Its what pretty much everyone does.

And that's precisely what the unannounced release blew up, my local
staged repo. 6.3 included a lot of new material, and the filesystem
with the local repo was getting cramped. I really can't get into why
that filesystem doesn't have more pace.. The release going out the
same day as the first general announcement doesn't leave enough time
to activate or expand storage. As it was, I thd to toss out my CentOS
4.x archive. (I'd used it for testing the Subversion 1.6.18 and 1.7.5
backports I've published over at https://www.github.com/nkadel/, do
check those out for help migrating off of CentOS 4.x and using much
better source control.)

On a host by host basis, this is compounded for folks who run "yum -y
update --downloadonly" to prestage their updates. That took..... quite
a lot of local disk space on a lot of hosts. And if you're somone who
allocates /var space cautiously or as a smallish separate partition,
it could be a real problem.

That's why I'm calling it an "unannounced release". The lack of
tentative release dates for CentOS has been only one of the reasons,
for me at least, to use Scientific Linux instead wherever possible. It
was a big problem with the 6.0 release, which took so very long, and
the 6.3 release which was pleasingly swift (and for which your group
shold be applauded!). But it was so fast it was a bit of a surprise