On Wed, 23 Feb 2011, Karanbir Singh wrote: > On 02/23/2011 10:01 AM, Dag Wieers wrote: >> No they can not. The bottom line is, people can try to reverse engineer >> the process CentOS is using, but they may never be sure it's like what >> CentOS did. So your statement is incorrect. > > I am not sure how to say this any other way, its been said many times > over and over again : we dont use any super magic juice anywhere, its > mostly just mock in a for loop. Lets assume that there still exists some > fear and doubt somewhere about the process in exact terms. The modifications (of the buildsystem/process) per package is the magic juice. Again I don't mind if that's the case, but if there's a reason it takes weeks/months for a release to go into QA, then obviously it doesn't all build fine in mock. > then lets take up the conversation on list where I said that once 6 is > our of the door, I'll document what and how things worked for the build > process ( including the pause's and why they took place. Would that > remove some of this FUD layers ? That would be great. The upside of having all releases in a small timeframe is that there's more time in between releases ! I don't think it's about FUD, fact is that people don't understand why it takes so long and don't understand why they cannot helps speed up the process. On the other hand some of the developers blame the ignorance of users, so a clear and transparent process may bring more people up to a higher level to understand and make better suggestions. >> Hence my joke that the 'C' in CentOS actually means Closed. > > I dont agree, if you said 'C' in CentOS is mispelled 'Slower than > ideal', I'd agree :) Of course, it's not completely closed. Looking in a thesaurus, the only thing coming close to 'Slow' in there that starts with a C is Constipated ;-) >> That said, if CentOS wants it this way they sure have every right to do it >> like this. But it would be nice to state that upfront. > > Propose a wording snippet ? Well, as you promised to open it up after the release, there's no reason to debate it now. Maybe some of the content of the presentation (pros/cons) should be on the wiki in an About section, it would at least change what people expected. I think the biggest problem is that people expect something else than what is implied, delivered and/or promised, maybe because in the past releases were quicker, or communication was different, or because one simply expects that more is being automated and hence releases are quicker. -- -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- dagit linux solutions, info at dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]