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