[CentOS-devel] are there any chances to see finished CentOS6 in 2011?

[R P Herrold]

On Sun, 26 Dec 2010, Farkas Levente wrote:

> can you show me one such example? when any outsider's help 
> was accepted?

Certainly, first specific as to you, Levente, and then 
generally as to the project receiving 'outsider's' help

I _know_ you received a detailed private email from me in my 
@owlriver.com context, addressing your rebuild problems just 
last week; they are, so far as I know, when taken with the 
public comment from an @redhat that they see the problem of 
PTYs in local mock instances, but not under koji, a complete 
solution

As to public input (an outsider) in eliding both trade marked 
content, and non-mandatory branding design concerns, Stephen 
Smoogen's efforts spearheading the elidement effort (before he 
went back to Red Hat) are a clear and extended effort by a 
non-CentOS insider, which greatly improved C5.  If it was not 
publicly recognized at the time, I assure you I noticed.  Let 
me say it again: Thanks, Smooge

Similarly the work of Akemi Yagi particularly on the -plus 
kernels, and the work on AMD K6-II capable kernels was of a 
non-insider and is greatly appreciated by me.  Thanks, Akemi


later:

From: Michal Piotrowski

>> My last post here noted that Red Hat ran a four month beta
>> program, AFTER their internal stabilization.

> Yeah, but I don't expect from CentOS any stabilization - 
> only  rebuild of packages.

Then your expectations of what CentOS provides are naiive and 
inaccurate

>> My blog post crossing 'planet.centos.org' made it clear

> Sorry, but I did not even realize that such thing as 
> planet.c.o exist. Also I did not realize that you and your 
> blog exist.

This behavior, for want of a more charitable way to 
characterize it, is simply insulting: to NOT do research, and 
to NOT read back freely open archive


Folks -- this is not rocket science, in the most part, but 
just laborious;  add a chorus of enough whiners and leeches, 
and the 'desire to scratch' an itch lessens that much more.


Take:
 	rpm -qlp redhat-logos.whatever.rpm
from upstream, and note all files, their forms, and their 
sizes; every one needs to be replaced, or be decided to be 
dropped (some side languages).  Anaconda-images seems to be 
gone still, merged into -logos, although is still referred to 
in Red Hat's trademark guidance page when I checked this last 
week

For each of those files, write the necessary code to emit 
replacements bearing CentOS branding and trademarks, in the 
place of that from the upstream

Rebuild all packages, and file bugs in the CentOS tracker when 
problems are encountered, and initially don't worry about the 
art

Solve additional packages needed to make it self-hosting if 
possible.  I've mentioned here before that my lead workstation 
has something over 1000 local custom packages of the roughly 
3000 on it.  I'm sorry, but it will be a cold, cold day before 
I spend my spare time to document something to satisfy idle 
curiosity of passive onlookers here

Then take another pass, and look at branding art and text, but 
not restricted trademark usage. The art which remains is 
(should) not be encumbered; cross check the package license 
details to be sure.  That said, if as a matter of branding, 
but not trade mark elidement, one feels a need to remove such, 
note it in the bug tracker, and the wiki page for 6

When replacements are completed, note solutions in the 
tracker

I am in restricted bandwidth, but from memory, the bug 
tracker is at:
 	http://bugs.centos.org/
and is a Mantis instance, converted from Bugzilla in the 
project's past.  If there is a true interest in ARBT automated 
filings, it would be easy enough to resurrect a bugzilla, but 
it is not clear who would tend it.  I've not seen a 
groundswell for such, and I don't see why we would add doing a 
task poorly to the project

No doubt someone will chime in with the CentOS wiki 6 
candidate link; as I say I am in poor bandwidth, and cannot 
search it out conveniently

As to searching CentOS specific answers, Google heavily 
indexes the project, and using a search argument like:
 	site:centos.org project bug tracker
will work, and is my usual approach

I omit discussion of package manifest, ldd library, and build 
environment verifications here.  I don't much care for 
exactitude on my local efforts as they will not become the 
CentOS 6 fruit, and slight variances which I see will be 
addressed locally post official CentOS release.  Also, I just 
do not care much about GUI package complete coverage, and so 
do not spend effort there

Next to install testing, automated install image makeup for 
anaconda for a 6 remains a problem for my efforts, and that is 
where I am working presently.  I remain convinced that 
upstream makes a great mistake (perhaps market demand driven, 
perhaps for other reasons such as getting out of the anaconda 
tweaking business [a sound goal]) in doing install time 
repository merging, as it makes the install much more fragile 
at least in a CentOS like context; perhaps when in an 
environment with a formal and commercial, SLA backed, error 
reporting CDN (content distribution network) behind it and a 
customer facing compensated support team, it makes sense

As I say, I am not convinced install time wire repodata and 
package retrieval works well for a CentOS model [I note there 
is a report seemingly with this as well in the testing of the 
SL alpha].  Performance is poor, the memory footprint is too 
large, and even in a local network environment, installs 'take 
too long'.  When we add the mirror network redirect model, we 
are going to see lots of complaints, I think, if we do not 
take steps to 'nail' an install to a single mirror result set 
for a complete install

We'll see, but I presently think it should be disabled, and 
left for a later yum pass.  This may cause problems in later 
point releases, however, as the merged package set of local 
base, optional local media archive updates, and remote archive 
updates at a point release may make some features non-directly 
installable in the future, of the upstream slip-streams in 
some new group overlays

Please note that I post from a non- at centos.org email address, 
and these are just my thought

-- Russ herrold