begin quote On Wed, 11 Aug 2004 03:50:04 -0400 Jeremy Maitin-Shepard wrote: > If you meant something else in your previous message, could > you please explain it? I believe I did argue -why- updating the main tree is a bad idea for an "enterprise" ("stable") release. *) Don't assume that ISV/Enterprise users won't want updates. They do. They count on it. Otherwise they would simply take a snapshot, run their own changes, QA it for a month and deploy... Erm.. No, thats the point of using a distribution, to not have to do that. *) Enterprise/ISVs -will- make modifications to their sources. Thats part of the point of running Gentoo for custom deployments. Its easy to customize Gentoo, thats one of our strengths. ( Yes, for servers they may well run unpatched and so on, however, even server deployments on large scale are likely to modify some packages. Fex. basic server configurations and so on. Its easier to change the default ntpd package + configs than it is to manually track n machines and do the same cut-n-paste changes.) *) Updates in main tree break upgradability of such trees. Badly at that. This is why I argue a separated release process, because then its simple to check "whats new" in the released tree, which will be a fairly -small- tree at that. Check fex. redhat's "errata" tree for their older distributions. Point example that invalidated debian from such a process, was this: 1) foobah in main tree released as stable. 1.2) internal bumps of foobah to patch some issues from upstream CVS that casued problems. (debian didn't consider this bad enough) and add config file changes to go into the package directly.( this is released in a separate, internal, apt repo. Sort of like having an Gentoo overlay tree) 1.3) upstream releases modified foobah into mainline. This means that the base version is modified, and there is no notice to others about this, because internal deployment has already taken the package five to ten revisions higher. The internal repo has predecent and and update doesn't work. With Gentoo the case would be the same, leaving systems vulnerable. I hope I have been able to explain the problems involved here. -- begin .signature Tortured users / Laughing in pain See Microsoft KB Article Q265230 for more information. end