EL 6 rollout strategies? (Scientific Linux)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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


[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux