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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
