On Jul 22, 2010, at 4:11 PM, Charlie Brady wrote:
>>> While of the above may seem obvious, the specific points are
>> 1) there are no steps and there is no process. Instead
>> its savvy guesses and spot checks and triple checks.
>> I would hope that there are some standard steps, rather than a totally
> ad-hoc process.
>
Results from an ad hoc or organized process are indistinguishible.
But "security" fixes are intrinsically ad hoc and unplanned by their nature.
>> 2) the bottleneck _IS_ in some sense the testing team,
>> who are expected to achieve the pretense of "perfection"
>> in spite of the "out-of-band" QA procedures involved.
>> You really start to think hard and carefully before claiming
>> WORKSFORME
>> when your reputation is at stake. Its embarassing when some
>> silly error has to be re-released or re-re-re-re-released to
>> achieve the desired "security" fix goal.
>> I have seen no evidence that the testing team is the bottleneck here.
>
We likely have different meanings for "testing team" which should be clear
from comments and context.
But if you mean the formal community cadre that tests new packages for CentOS
before they are called "released" (my meaning was different), then what are
you waiting for? When @redhat releases security fixes there is _ALWAYS_
a SRPM involved. What stops the "testing team" from attempting rebuilds
and i9nstall directly from what @redhat releases? And what stops
gathering the security fixes on some web site for additional vetting?
In short:
What's the beef with CentOS "security" releases and testing teams
and community involvement?
If the existing CentOS processes aren't moving as fast or smoothly as one would like,
why not spend the energy doing an end-around rather than droning on criticism?
I personally know a large number of the people involved with CentOS (even if I
don't directly use or participate with the CentOS project). None of them
are gonna stop anyone from trying to do whatever seems needed IMHO. YMMV.
>> Security "fixes" are a hard problem to solve in _ALL_ distros, not just
>> CentOS.
>> My expectation is that it is actually an easier problem for CentOS. They
> don't need to consider whether it is the correct or best fix, just whether
> it has been built correctly, and produces build output "sufficiently
> similar" to that produced by upstream.
>
This is the same QA process for "security" releases that I described. The
"fix" assumes a cookie cutter gear turning build system, and that typically
isn't the case, there's a fair amount of additional effort needed to ensure
that "security" fixes are rebuilt perfectly.
Go grab "security" fixes SRPM's from @redhat and rebuild, install, test, on all
supported platforms if you wish to see what effort is involved.
73 de Jeff