SCIENTIFIC-LINUX-USERS Archives

August 2012

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Reply To:
Date:
Tue, 21 Aug 2012 01:40:02 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (66 lines)
I'll assume you meant this for the list..

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?


>
>>>> Not FUD at all... in fact, it is a truism.
> And many truisms are wrong much of the time. This is one of them: far
> too many systems and system administrators follow this truism and wind
> up vulnerability to quite virulent security and performance problems.

That doesn't make sense in a logical, technological or grammatical 
sense. I have no idea what you are trying to say here.

>
>>> Workout the answer to the question above and look back at previous
>>> threads on this list about the same thing. The OP is nothing but FUD.
>> To be fair to the OP, if you are going to call someone out on FUD, you
>> really IMHO ought to give a lot more detail as to why, otherwise you are
>> merely perpetuating your own FUD.
> 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?

ATOM RSS1 RSS2