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.
