On Tue, 17 May 2011, Radu Gheorghiu wrote: > The main "fear" the developers have is that somebody could > steal their work and come up with another RHEL clone easily > if they release their build system & scripts. > I think this is obvious by now. 'obvious' to you or not, such is not the case with my view of the matter, nor indeed my practice .... not that CentOS is just the fruit of a binary build solution. The attention to 'getting it right' the first time, the trademark and branding changes, the art, the bug tracker, the mirror network and its 'backside management,' the mailing lists, IRC, forum, and wiki and more are 'part of the package' as well. Shall we also stop and describe how to set up Mailman, administer IRC channels, in formal detail? Doing so will do nothing to attain the 'goal' which I assume a vast 'silent majority' are eagerly awaiting Some others have set up alternative approaches ** even working forward from CentOS' of build SRPMS ** -- SME Server, and ClearOS come to mind, but their goals differ CentOS is not diminished by Scientific Linux, nor vice versa. I have communicated cordially with them on matters of common interest for years SME has such radically different goals as a project that people do not recognize the current CentOS roots; ClearOS again had its own 'take' on the release contents, and has recently announced an intent to fork away from using CentOS SRPMs after several years following CentOS. Some of the build group from each were in the QA group for a while. There are other RPM based, upstream derived, rebuild projects out there as well, that a person has to look closely, and know the history, or read the sources, to see where they came from I've repeatedly published my approach to the build solve, including a solution written after solving the parts of upstream's '6' sources in which I am interested. I have such running in private release. I've offered several times here to offer private guidance 'through the rough spots' for people attempting such a upstream cloning Some of the earliest content in the CentOS wiki was articles about build environments, and building as non-root, predating the transition by serious builders to mock and other 'in a clean chroot' approaches But the build for the first bootstrap '6' does not encounter the same issues that '5' or '4' encountered. I've said that as clearly as I can before, as have others on the CentOS build group, and people who treat a rebuild as a thought experiment to be talked to death, will NEVER understand that. One has to DO it, to see and understand the way the solution to the rebuild problem mutates over time I see later in this thread 'conspiracy theory' reference' to a 'massive code base' --- what a crock. Build-systems dating from the old Red Hat RHL 'beehive' fifteen years ago started as Rube Goldberg contraptions needing constant love and attention from their tenders. I am told by one such 'tender' from that era, that it always seemed to break after midnight, necessitating sometimes 'driving back to office' to repair and restart The 'state of the art' as to packaging, and automation change over time, but there still needs to be a person who understands the build automation system, able to go in a "'kill' a hung job" and experienced eyes to diagnose and patch around the inevitable problems that surface in the final few percent of the packages. And anyone who thinks that patching 'anaconda' (the installer) is a well defined task has no conception of the enormity of the changes over time that anaconda has gone through. I am tremendously unhappy with the changes with the anaconda TUI mode under upstream's '6' and once a CentOS 6 emerges, I can foresee much support load with people adversely affected A couple have actually followed through the work of rebuilding and integrating the upstream's '6' sources (not the people who would rather carp and troll here, of course), and I've mentioned privately helping other people building the latest upstream sources from scratch with their efforts. At least two have working sub-sets to their interest and project goal, complete with installers, at the upstream's '6' level heck -- In looking at my local developmental 'crash and burn' laptop, which started live as a CentOS 5 unit 14 months ago, I see over 30 ** POST ** upstream '6' level packages. Looking, I see that my day-to-day office developmental workstation (a bit over three years old at this point) has 1101 of 2287 total packages that are local deviations from C 5 (mostly pushing in financial and statistical tool-chains, but also developmental tools ... automake, m4, libtool, and so forth) Sometimes to reproduce a bug, I need to deploy a fresh machine image, just to make sure my local changes to not mask something -- the changes by upstream to the named configuration files generation comes to mind as one I needed to 'revert' back to a clean install, to see what in the world the reporter was seeing It is a simply false to fact to reach your 'obvious' conclusion [I see 14 new posts within the past hour that composing this piece has taken ... If I had known the comment by 'Radu Gheorghiu' was coming, about 'waiting for somebody to come and fill their pockets', I would have spent it productively instead. I think hughesjr was right with his comment that speaking here is just not worth it --- I'd rather get work done than talk in such a hostile environment] -- Russ herrold