On Mon, Aug 20, 2012 at 8:40 PM, Ian <[log in to unmask]> wrote:
> I'll assume you meant this for the list..
Yeah, I did. I'm bouncing around mal clients and browsers lately.
(Working with a hot new MacBook., got some virtualized Linux OS's on
it, inlcuding Scientific Linux.)
> On 21/08/12 00:54, Nico Kadel-Garcia wrote:
>>
>> On Mon, Aug 20, 2012 at 7:22 PM, Ian <[log in to unmask]> wrote:
>>>>
>>>> you are over simplifying the process. Eg. What was the time lag from
>>>> when the srpm was released and the rhn notes published to when CentOS
>>>> released that specific update ?
>>>>
>>> I seriously think this is the wrong place to discuss CentOS specifically,
>>> don't you?
>>>
>>> But, I'll humour you... if somehow, Delay= CloneReleaseTime -
>>> SrpmReleaseTime = 0 (i.e. no delay) then I fail to see where your testing
>>> time is.
>>
>> I'm afraid you've not actually followed what Karanbir wrote. He
>> pointed you to the CentOS release process: Both they, and Scientific
>> Linux, get the tested and released source packages from the upstream
>> vendor, rebuild them, publish first to a testable software channel,
>> and only then release to the main deployments.
>
>
> *In this thread*, where is this process document to or linked to, because I
> missed it or it wasn't here.
>
>
>
>>
>>> If you consider:-
>>>
>>> Delay = CloneReleaseTime - SrpmReleaseTime -
>>> AcceptedRebuildAndIndependentTestTime = 0 then maybe.
>>
>> And if the chocolate cake and the pizza and the french fries had zero
>> calories, we wouldn't gain weight eating them. But not a single one of
>> the periods you've listed above is "0".
>
> My point exactly. Any clone will have "delay". Delay being the time between
> RH release and clone release. You can force it closer to zero by chopping
> bits out of the process, e.g. such as your own testing. The more you push it
> to zero, the less time you have for testing. Is this not obvious?
Even if it's the point you meant, it's not the point you made. Our
upstream vendor, and our rebuilders, do insert the inevitable phase
delay of rebuild times from the original source code, which our
favorite upstream vendor publishes for us as SRPM's. Each of those
builds, and the pre-release versions published in their development
channels, include some modest testing and provide opportunities, often
used, for actual testing.
By the time it's actually released, it's usually pretty well tested,
especially from a reputable vendor whose support calls are one of
their biggest corporate costs. There are sometimes feature changes and
discrepancies that can cause issues, but this is not the same as
saying they've not been tested.
>> Nonsense. Karanbir has pointed you to a specific release process. Go
>> review it, and see that every single step you describe as "0 time" is,
>> in fact, performed. They're also a tough trade-off to make: more
>> testing might catch more regression bugs, but less testing can get a
>> critical and outstanding condition addressed more quickly and
>> productively. My example of Subversion was just such an issue. The
>> silent, default use of plaintext stored passwords in version 1.4.2 was
>> an outstanding and very serious bug, well worth the jump, even at the
>> risk of some compatibility issues.
>
>
> Again, where did he point this?
He pointed you to the CentOS release process. Though not active on
those mailing lists anymore, I can point you to the parallels in the
Scientific Linux release process: the SRPM's are published, they work
from the already tested upstream vendor source to the legal limits of
trademark and other licenses, and they publish the pre-release code
for early testing before putting in the mainline updates.
There are cases where new releases, especially with security tweaks,
cause issues. I cited Subversion as a prize example.
|
