Re: EL 6 rollout strategies? (Scientific Linux)

[Les Mikesell <lesmikesell@xxxxxxxxx>]

On 5/18/2011 8:23 AM, Brunner, Brian T. wrote:
>
>> There's also a reasonable question about whether this process could
>> be better automated,
>
> How do you *automate* a system where the fundamental rules change
> 'without notice to users'?

You have the results you want to reproduce.  You have a list of likely 
suspects for the components involved (some of which may be the same as 
your binary results). You have a way to test if your output is a 
reasonable match. The part in between can either be brute force trial 
and error, predictions based on hints from file or source change 
timestamps on the components and target outputs, looking at the library 
linkages you want to reproduce, or some combination thereof. The 'list 
of likely suspects' and where to find them might be hard to automate but 
it's something that might benefit from more eyes.

>> in which case it becomes typical software development for programs
>> that solve the dependencies and find and assemble the requirements.
>
> Rebuilding somebody else's sources without their build environment isn't
> typical.  It's MindReading 101.

Whether a computer program can simulate mindreading better than a person 
(reading someone else's mind)is still up in the air.  My money would be 
on the computer going forward anyway, especially if speed is one of the 
ways you judge the results.  Whether exposing the process to the 
community would ever result in such techniques being developed or even 
scaling out the brute force approach is equally speculation.  The more 
fundamental question here is whether the current timeframes are a 
problem for anyone or if there is any need to change the existing 
process.  And that discussion seems to be off limits with the only 
choice being to switch to a different disto or start a new project if 
you don't think the existing approach is perfect.  At this point that 
discussion is probably counterproductive for this release, but the 'open 
is better' suggestions have always been brushed rudely aside. At least 
there _is_ another distro suitable at least for testing purposes.

-- 
   Les Mikesell
     lesmikesell@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos