Philip Brown wrote: > I'd like to see if I'm properly understanding what you wrote here, Bart, > > > Bart Smaalders wrote: >> There will be no changes in the kernel makefiles in terms of building >> the kernel. Packages will be delivered to a repo rather than >> being created on disk.... >> >> If the type IDs in genunix change, I assume its elfhash changes. >> Likewise, if the dependent modules change, their elfhashes will >> change as well. >> >> All the bits that changed as the result of this build will appear >> in the same package updates. >> >> Eg if the build produced a different genunix, disp and devfs, >> those three modules will appear as different in the next rev >> of the core kernel package(s), and always will be installed as a unit. >> >> The model of picking and choosing kernel components generated over >> various builds from the past two years will be a thing of the past. >> >> No more "dim sum" patching! > > It SOUNDS like you are saying something like the following: > > - There will be a [core kernel] IPS "package" > - Users will have a choice of choosing the equivalent of > REV.2007.MM.DD of kernel package, or REV.2008.MM.DD of kernel package; > they will no longer have a choice of "patch kernel module X" > - This is better then what sun does now, because sun allows/provides > "patch kernel module X" at the moment > > So, you're happier with "the new system", because it doesnt allow for that > last possibility. > > Please correct me if I'm wrong here, but... at a functional level, how is > this different from Sun just deciding, > > "We're no longer going to provide piecemeal patches: We are only going to > provide 'patch rev XX for SUNWckr'. We are not going to provide 'patch rev > YY for subcomponent foo of SUNWckr." > > To put it another way; you plan to "fix" the software maintainance process > at Sun, by taking away the ability to do piecemeal patching, rather than > going through a management path of simply telling engineering at a > managerial level, "stop releasing piecemeal patches". > > Does that accurately sum things up? > >
That's one way of looking at it... but if you take a look at what happens with the kernel jumbo patch, very shortly after each patch rejuvenation we're essentially doing the same thing already. The inevitable result of large scale rates of change in S10 has been the effective "gluing" together of large numbers of patches as large projects put back and affect 100's of files in the resulting builds; this causes the massive accumulation of patches and results in the monster kernel update patches seen in the S10 updates. As a result of this, we switched in S10U4 to a different model of patch construction, which basically releases each update as a small set of large patches that obsolete any previous patches; that patch is immediately rejuvenated and subsequent patches released after that update require the installation of the update patches. This has moved customers to a much more linear patching model for kernel updates, much as we expect to do for Solaris 11. As a result of doing so, the effort involved in building "patches" is greatly reduced... and this should allow Sun to offer multiple streams of change for S11. One of the great difficulties for our S10 customers is coping with either too slow a rate of change in terms of ZFS updates, etc, or too rapid change for those not needing any new features. By automating the production of software updates (no prepatch/postpatch scripts, backout scripts, etc), we should be able to offer a stream of change that accepts only critical fixes for a year... and another than provide that change much more frequently. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
