Hi all,
Would it be possible to release CentOS EUS with their respective patches like upstream vendor does?? For example two releases or one release back: 5.4 and 5.3 or 5.4 only.
Why? Because for example for important bugs detected on upstream 5.5 version like this: https://bugzilla.redhat.com/show_bug.cgi?id=583218. This bug doesn't exists under 5.4 release, and IMHO, it is a very important bug (it is marked as urgent on upstream).
I think it would be nice to have the possibility to choose between one version and another according to the problems that arise.
Many thanks.
carlopmart wrote:
Hi all,
Would it be possible to release CentOS EUS with their respective patches like upstream vendor does?? For example two releases or one release back: 5.4 and 5.3 or 5.4 only.
Why? Because for example for important bugs detected on upstream 5.5 version like this: https://bugzilla.redhat.com/show_bug.cgi?id=583218. This bug doesn't exists under 5.4 release, and IMHO, it is a very important bug (it is marked as urgent on upstream).
I think it would be nice to have the possibility to choose between one version and another according to the problems that arise.
Many thanks.
Can you imagine the work behind maintaining 5.y itself ? So adding sub-branches like 5.x.z is not feasible and it was discussed the need or not to provide and support such .z branches. I can understand that such bug isn't good to have on production machines, but if you still need such support on production machines, why not subscribing to the real .z branch maintainer, aka Red Hat ? Just my personal opinion though ..
Fabian Arrotin wrote:
carlopmart wrote:
Hi all,
Would it be possible to release CentOS EUS with their respective patches like upstream vendor does?? For example two releases or one release back: 5.4 and 5.3 or 5.4 only.
Why? Because for example for important bugs detected on upstream 5.5 version like this: https://bugzilla.redhat.com/show_bug.cgi?id=583218. This bug doesn't exists under 5.4 release, and IMHO, it is a very important bug (it is marked as urgent on upstream).
I think it would be nice to have the possibility to choose between one version and another according to the problems that arise.
Many thanks.
Can you imagine the work behind maintaining 5.y itself ?
Yes, I can imagine, but just wondering if that possibility could exist.
So adding
sub-branches like 5.x.z is not feasible and it was discussed the need or not to provide and support such .z branches. I can understand that such bug isn't good to have on production machines, but if you still need such support on production machines, why not subscribing to the real .z branch maintainer, aka Red Hat ? Just my personal opinion though ..
I have a paid subscription from RedHat for my prodcution systems, but my devel and test environments are CentOS, and all of them boots from a SAN via iSCSI storage ...
Thanks.
On Wed, Sep 22, 2010 at 10:21:00AM +0200, carlopmart wrote:
Yes, I can imagine, but just wondering if that possibility could exist.
if the src.rpm were public..
I have a paid subscription from RedHat for my prodcution systems, but my devel and test environments are CentOS, and all of them boots from a SAN via iSCSI storage ...
centos.org does not.
Tru
On 09/22/2010 09:34 AM, Tru Huynh wrote:
On Wed, Sep 22, 2010 at 10:21:00AM +0200, carlopmart wrote:
Yes, I can imagine, but just wondering if that possibility could exist.
if the src.rpm were public..
Yeah, last time we checked - not all V.R.z pkgs were being put out - quite a lot of the z-series work was being done internally at RH for specific client needs against nice chunky costs.
Can you not cherry picking with a V.*; moving up and/or down isnt that much of a deal.
- KB