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
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
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
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
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
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
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 -
Marcus Moeller