On Tuesday, August 21, 2012 12:30:01 PM Konstantin Olchanski wrote:
> F = fear
> U = uncertainty
> D = deception
> 
> what did I say that qualifies? There is no "S" there for "stupid" or "O" for "obvious".

D = 'doubt' not deception.  That is, make someone doubt something.  'Stupid' and 'obvious' things can create 'doubt' and are part of the standard FUD toolbox.

But, really, if the buildsystem is producing binaries that verify (with rpmcompare or similar tools) from the upstream, already QA'd, sources, if the package that was rebuilt within minutes of the upstream source RPM release passes the automated QA process why not sign and release it?  The bulk of the QA is done upstream, after all.

It is quite possible that the SRPM shows up, an automated buildsystem grabs it from upstream, rebuilds in an automated manner, runs automated QA tests, and it gets in the release queue, and one of the rebuilders (from either SL or CentOS) quickly does whatever manual QA needs doing, finds that it successfully passes QA, then signs and releases the package, all before the upstream e-mail announcement makes it to a particular upstream user, depending upon maillist server software and network lags (and mailserver loud, etc).  That can happen, especially if the maillist server is heavily loaded and the package is a quick and easy rebuild with minimal QA required, and a rebuild QA/developer happens to be available to do 'instant' QA/sign/release.  I wouldn't expect it to happen every time (or even often), but it is still a possibility.

In the particular CentOS case, the idea is to be 'bug-for-bug compatible' and as identical to upstream as is possible, bugs and all.  Scientific Linux has slightly different goals, and thus has a different process.  Even if both projects have the same number of developers/rebuilders working the same number of hours using identical buildsystems it wouldn't surprise me to see different release times simply due to the different goals.  Other than a simple 'both projects are pretty quick' such an analysis has little use, really.  There are too many variables (developer availability, network speed/lag, buildsystem load, maillist server load, etc) to derive anything concrete, statistically speaking, from 'time between upstream release to rebuild release' on a package-by-package basis.   (Defining what 'release' means is one of the most critical aspects of this, too. In this particular study's case, it's the release of the advisories, not the packages themselves, that is being measured.)

Unless something is drastically amiss this sort of 'race' is a useless exercise (except to battle some FUD by a third party that I'm not mentioning by name...).  Both projects have full-time developers at this point, and both projects are putting out quality packages at a good rate with excellent QA.  Especially for something free and open.  Now, it is true that in the buildup to the release of CentOS 6.0 things looked pretty amiss at the CentOS project, but my takeaway from that situation is that the CentOS team learned some very valuable lessons; these numbers do tell that they have improved dramatically in their efforts.  SL's early move to a newer buildsystem seems to have served them well, and masked the very difficult process of the initial 6.0 rebuild.  

Seems I recall SL starting on the rebuild nearly six months prior to the upstream EL6 release, based on the upstream public beta, on using koji for the building, and thus they (apparently) did get a headstart on the process.  If you want Troy's take on it, go back in the SL archives and look for a thread from last July with the subject 'recipe for rolling SL6 from TUV SRPMs?' and see what Troy thought of the idea that a couple of interns could do the job over a summer.  A quote from Troy in that thread: "Building the initial SL 6.0 rpm's was very painful."  But you need to read his full reply to get the full flavor, and that's in the archives, so I won't quote it in full here.....

SL does have the more complex release process of the two due to the 'security fix only and be able to stay on a point release' model (see recent Xorg update issues for an example of a complication SL experienced that CentOS did not, due to that model).  That is one of SL's goals, and makes things harder for SL.  So the variance is totally unsurprising and should be completely expected.

To reiterate; at this point in the EL6 cycle, both projects are doing a fantastic job and both are to be commended for their not insubstantial efforts at successfully doing this nontrivial task.  SL and CentOS are not direct competitors, and should not be treated as such.  IMHO, YMMV, etc.

And I'm well aware that the article mentions the reasons why the study was done, and the third-party that triggered it, etc, but I'm not considering that third party in my comments.