FAQ
Hi all.

In general the release of CentOS 6 has been appreciated a lot in the
German-speaking countries. But a lot of ppl complained about how updates
are handled in transition phases between minor releases (e.g. 5.5 to 5.6).
From what I can see on the announce list there has be a lack of updates
for about two month:

http://lists.centos.org/pipermail/centos-announce/2011-February/thread.html
http://lists.centos.org/pipermail/centos-announce/2011-March/thread.html

where some critical updates where pending.

I remember that we once agreed that if a critical update has been
released during transition phase, it should be backported.

Maybe we have to completely re-think the process. I guess the main aim
is to keep minor releases (the ones that are shipped on the media) in
sync with upstream. They should not contain newer packages, then
upstream to keep compatibility on release date.

But on the other hand, already installed systems need to be patched.

I am not completely sure how this scenario is handled atm but if not
already done this way, i would suggest that the majorversion directory
(e.g. 5/) should be fed with these missing updates so that they become
nearly next-minor. Similar to what is planned for 6.0 -> 6.1

Besides that the minor release trees (e.g. 5.7/) should only contain
packages that are part of the release, no post release updates, on
release date.

Greets
Marcus

Search Discussions

  • Karanbir Singh at Jul 12, 2011 at 6:22 am

    On 07/12/2011 08:11 AM, Marcus Moeller wrote:
    Hi all.

    In general the release of CentOS 6 has been appreciated a lot in the
    German-speaking countries. But a lot of ppl complained about how updates awesome1
    are handled in transition phases between minor releases (e.g. 5.5 to 5.6).
    erm, we addressed this a while back with the conversation about the CR
    process ( its even mentioned in the C6 announcement )

    in a nutshell, there are 4 key facts :

    - all updates are provided in a sane build ( ie, some tests have been
    done and they *should* be all in a good state ); its not easy to isolate
    the SA's only, it would need to be everything

    - Its not dropped in by default, the user would need to make a manual
    choice to opt into this repo

    - We need to think about, put in place and execute a very visible and
    very focused education campeign to make sure that a large number of
    people are aware of its existance, know what the implications are, and
    have the facts they need to make a decision.

    - The process needs to gurantee an exit strategy / rebase to <rel>/os/ +
    <rel>/updates when a point release is publicly available with media.

    We are getting this ready for 6.0/CR/ at this very moment ( and it might
    be a few days before it starts seeing rpms ) - so if there are things
    that need bashed out or spoken about or design issues that concern
    anyone, now would be a great time to share

    - KB
  • Marcus Moeller at Jul 12, 2011 at 6:39 am
    Hi all.
    In general the release of CentOS 6 has been appreciated a lot in the
    German-speaking countries. But a lot of ppl complained about how updates awesome1
    are handled in transition phases between minor releases (e.g. 5.5 to 5.6).
    erm, we addressed this a while back with the conversation about the CR
    process ( its even mentioned in the C6 announcement )
    Sorry, have unsubscribed from -devel for a while because I was tired of
    troll discussions, which happened recently :)
    in a nutshell, there are 4 key facts :

    - all updates are provided in a sane build ( ie, some tests have been
    done and they *should* be all in a good state ); its not easy to isolate
    the SA's only, it would need to be everything

    - Its not dropped in by default, the user would need to make a manual
    choice to opt into this repo

    - We need to think about, put in place and execute a very visible and
    very focused education campeign to make sure that a large number of
    people are aware of its existance, know what the implications are, and
    have the facts they need to make a decision.

    - The process needs to gurantee an exit strategy / rebase to <rel>/os/ +
    <rel>/updates when a point release is publicly available with media.
    Okay, so this CR repo is meant to be some kind of rolling (maybe similar
    to SL's rolling repo)? In fact, there should not be a problem to get
    back to the os/ updates/ repo as it's all about package versions. Of
    course, if one switches back during a release, he/she will have a mixed
    env, but it will be cleared on next point release.
    We are getting this ready for 6.0/CR/ at this very moment ( and it might
    be a few days before it starts seeing rpms ) - so if there are things
    that need bashed out or spoken about or design issues that concern
    anyone, now would be a great time to share
    Is it planned for the complete cycle or only till 6.1 has been finished?
    Because it sounds like a good idea, in general.

    Greets
    Marcus
  • Karanbir Singh at Jul 12, 2011 at 6:51 am

    On 07/12/2011 11:39 AM, Marcus Moeller wrote:
    Okay, so this CR repo is meant to be some kind of rolling (maybe similar
    to SL's rolling repo)? In fact, there should not be a problem to get
    back to the os/ updates/ repo as it's all about package versions. Of
    course, if one switches back during a release, he/she will have a mixed
    env, but it will be cleared on next point release.
    its actually not a rolling repo, in that you will need to have os/ and
    updates/ enabled in order to use CR/ for anye ffect, and rpms will be
    deleted from CR/ once a point release happens. So its not a case of
    opt-in, and leave it running forever ( we could do that as well, but
    before we end up with users tied in permanently, I feel it would be good
    to air the plan with the 6.0 -> 6.1 build cycle - ensure we are ticking
    the right boxs with the right sort of solution )
    We are getting this ready for 6.0/CR/ at this very moment ( and it might
    be a few days before it starts seeing rpms ) - so if there are things
    that need bashed out or spoken about or design issues that concern
    anyone, now would be a great time to share
    Is it planned for the complete cycle or only till 6.1 has been finished?
    Because it sounds like a good idea, in general.
    the process is in place for the 5.6/ to 5.7/ build cycle, I'm adapting
    that for 6.x now, the plan is to keep it in place and use it everytime
    there is a new release ( provided it works as expected )

    - KB
  • Marcus Moeller at Jul 13, 2011 at 4:04 am
    Dear Karan.
    Okay, so this CR repo is meant to be some kind of rolling (maybe similar
    to SL's rolling repo)? In fact, there should not be a problem to get
    back to the os/ updates/ repo as it's all about package versions. Of
    course, if one switches back during a release, he/she will have a mixed
    env, but it will be cleared on next point release.
    its actually not a rolling repo, in that you will need to have os/ and
    updates/ enabled in order to use CR/ for anye ffect, and rpms will be
    deleted from CR/ once a point release happens. So its not a case of
    opt-in, and leave it running forever ( we could do that as well, but
    before we end up with users tied in permanently, I feel it would be good
    to air the plan with the 6.0 -> 6.1 build cycle - ensure we are ticking
    the right boxs with the right sort of solution )
    So the CR repo will contain packages from the next minor, or from the
    next minor and beyond?

    e.g. during transition from 5.6 to 5.7 will it contain only packages
    from the upcoming 5.7 minor? As upstream might have released sec updated
    for 5.7 already, which might be useful, too.

    The disadvantage of pulling updates from beyond minor would be that a CR
    enabled system is in a somewhat undefined state (what I would call
    rolling), but equipped with the latest updates.

    Greets
    Marcus
  • Karanbir Singh at Jul 13, 2011 at 3:14 pm

    On 07/13/2011 09:04 AM, Marcus Moeller wrote:
    So the CR repo will contain packages from the next minor, or from the
    next minor and beyond?
    the 'plan' was to have everything from nextrelease + updates in nextrelease.
    The disadvantage of pulling updates from beyond minor would be that a CR
    enabled system is in a somewhat undefined state (what I would call
    rolling), but equipped with the latest updates.
    yes, its that bit which makes things a bit uncertain and why I feel that
    it should be by opt-in rather than by default; we just need to make sure
    that we are able to reach out to the users and create enough of a
    simple-knowledgebase around this subject so people can make the choice.

    Also, keep in mind that 5.6/CR/ goes away with 5.6 ( ie: when 5.6 moves
    to vault, there is no /CR/ migrated to vault, it just goes-away goes away )

    - KB
  • Marcus Moeller at Jul 13, 2011 at 3:26 pm
    Dear Karan.
    So the CR repo will contain packages from the next minor, or from the
    next minor and beyond?
    the 'plan' was to have everything from nextrelease + updates in nextrelease.
    Thanks for pointing that out.
    The disadvantage of pulling updates from beyond minor would be that a CR
    enabled system is in a somewhat undefined state (what I would call
    rolling), but equipped with the latest updates.
    yes, its that bit which makes things a bit uncertain and why I feel that
    it should be by opt-in rather than by default; we just need to make sure
    that we are able to reach out to the users and create enough of a
    simple-knowledgebase around this subject so people can make the choice.

    Also, keep in mind that 5.6/CR/ goes away with 5.6 ( ie: when 5.6 moves
    to vault, there is no /CR/ migrated to vault, it just goes-away goes away )
    That's what I thought.

    So, will there be cr-release package available for 5.x and 6.x soon?

    Greets
    Marcus
  • Karanbir Singh at Jul 13, 2011 at 4:15 pm
    Hi,
    On 07/13/2011 08:26 PM, Marcus Moeller wrote:
    So, will there be cr-release package available for 5.x and 6.x soon?
    for 6.0 yes, for 5.6 only once 5.7 is released upstream. Dont know when
    that is likely to be; I am guessing somepoint in early August.

    - KB

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcentos-devel @
categoriescentos
postedJul 12, '11 at 3:11a
activeJul 13, '11 at 4:15p
posts8
users2
websitecentos.org
irc#centos

2 users in discussion

Karanbir Singh: 4 posts Marcus Moeller: 4 posts

People

Translate

site design / logo © 2022 Grokbase