[CentOS-devel] CentOS-[56] Continous Release

Wed Jun 22 17:09:55 UTC 2011
Ljubomir Ljubojevic <office at plnet.rs>

Les Mikesell wrote:
> On 6/22/2011 4:17 AM, Ljubomir Ljubojevic wrote:
>>> I'd expect it to be common for the kernels and probably glibc's included with a
>>> point release or soon thereafter to include security fixes.  If you push those,
>>> you have the biggest risk of affecting everything else - so what's the point of
>>> isolating the rest?
>>>
>> All I can see is you pushing extreme case scenario on something that is
>> good will of the devs to lower aggravation of people waiting for point
>> release to be completed, with agenda to push for 2-days delay between
>> upstream and CentOS point releases, knowing it can not physically
>> happen. It's like watching my 2-years old nephew screaming for his
>> bottle of milk even tho he can see his mother pouring it just in front
>> of him.
> 
>> The packages that **can** be released faster *will* be released faster,
>>    those that could brake things will be held back, it is simple as that,
>> at least in my book.
> 
> It's speculation at this point, but I think security fixes in the kernel 
> and major libs are to be expected instead of being some extreme case, 
> and those are precisely the most likely things that would cause 
> something to break if done incorrectly.  The point of planning the early 
> release concept in the first place should be to get these fixes out to 
> the people who otherwise become targets of well-known exploits and 
> rootkits.  Assume, for example, that another flaw is found in php or a 
> web app that allows remote command execution, and another glibc flaw 
> like the one recently fixed that allowed root escalation if you could 
> make a symlink to a suid file.  Now assume that the fixes for these 
> vulnerabilities comes in or immediately after the point release. That 
> scenario seems normal, expected, and what the early release planning 
> should be all about instead of holding these back until a working 
> ananconda and iso layout is ready and tested.

So in another words, you approve creation of CR repository in it's 
current designed form.

And you also support devs when they release important security related 
packages through "updates" repo as fast as humanly possible, just I 
failed to understand what you are saying.

> 
>> I will even dare to speculate that main reason for people to opt-in for
>> CR repo will be so they can see how many packages are finished and to
>> see packages coming out so they do not freak out without a visible
>> progress.  Side affect will be that some of them will be able to busy
>> them selfs with comparing against upstream packages.
> 
> I think this is unlikely - unless they are unaware of the pending 
> security issues, don't watch the news, and never look at their logs - or 
> don't have an internet connection.
> 

Ljubomir