Yes we can move it. Does 11:30am PST work ok? Sent from my iPhone
On May 13, 2009, at 10:46 AM, Jack Schwartz <Jack.A.Schwartz at Sun.COM> wrote: > Hi Evan. > > I may not be able to make that time as I have an appointment > beforehand. Is it possible to change to 11 AM PT or later please? > > Thanks, > Jack > > On 05/13/09 09:04, Evan Layton wrote: >> I would like to have a meeting on Thursday 5/14 at 10am PT to >> discuss the Version Compatibility work. Please let me know as soon >> as possible if this time doesn't work so we can find a better time >> for everyone. >> >> The agenda will cover the following: >> - go over Ethan's installer compatibility write-up. (While this >> only covers the current package-based installs it is a good >> place to start) >> - please read over this write-up and be ready to discuss. >> - What does compatibility mean >> - what needs to change in the current problem statement. >> - go over other questions: >> 1) How do we determine which version we are running the >> install on vs which version we're installing. >> 2) How do we determine what makes the OS versions compatible? >> 3) How do we keep track of which OS version is compatible >> with installing which OS versions? >> 4) Do we know what the use cases are (see bug 7838 for some of >> this but more related to manifests). >> 5) What are the incompatibilities? >> 6) How do we handle these incompatibilities? (errors, >> warnings, >> take corrective actions if possible...) >> - What overlaps do we think we may have with the XML parsing work. >> This refers to forward and backward compatibility of manifests. >> - open discussion >> >> Teleconf number: >> Internal extension x44405 >> US-based: 866-545-5220 >> International: 213-787-0527 >> PC: 6343344# >> >> Thanks, >> -evan >> >> ==================================================================== >> Proposal for installer compatibility with pkg-based installed bits. >> (Fom March 23rd) >> >> As discussed in the meeting today, bug 7837 has been filed to >> address handling this issue long term. >> >> Bug 7838 is filed to log the installer and installed system's >> build numbers in the install_log. This one will be fixed for >> this release. >> >> AI docs will also be updated to note this. >> >> >> thanks, >> -ethan >> >> >> Ethan Quach wrote: >> > >> > thoughts welcomed on this ... >> > >> > thanks, >> > -ethan >> > >> > >> > Problem/Background >> > ---------------------------------- >> > With pkg-based installs, we've run into some incompatibility >> > problems as we've released later development builds that >> > aren't compatible with older installers, as seen in a few posts >> > from early triers of AI. This will be an on-going issue as we >> > develop new features into the installer, and we currently don't >> > handle this as nicely or intelligently as we could. >> > >> > >> > Proposed Solutions >> > ------------------------------- >> > [0*] Download the installer from pkg branch requested to be >> > installed. This solution involves extreme refactoring of the >> > installer architecture to dummy-down the install media, and >> > to store the real guts of the installer elsewhere. This solution >> > is not being considered for this proposal, but isn't precluded >> > from any future rework. >> > >> > >> > [1] A simple, conservative, solution to this problem would be to >> > restrict that install media only be able to support pkg-based >> > installs for packages of the same build as was used to build the >> > install media. >> > >> > Since in most cases, a random development build N install >> > image could potentially, and usually likely, be able to install >> > pkg-based bits of build N+1 for example, the enforcement could >> > be lightweight --perhaps just a warning message on the console >> > and/or log. E.g. >> > >> > WARNING: The build of the packages being installed, build X, >> > is not supported by this installer which was built using build Y. >> > Install will proceed, however the installed system is not >> > guaranteed to be installed properly. >> > >> > >> > [2] Embed variability into the process such that the install image >> > is able to determine if the pkg branch being requested to be >> > installed is supported by it. For example, use an install image >> > built from build N to do a pkg-based install of build N+2. The >> > installer knows its able to support this scenario and allows the >> > install to complete with no warnings. This provides more support >> > flexibility to the user, but requires a little more upfront work >> from >> > development. >> > >> > >> > Initial Impl. Details for [2] >> > ------------------------------------------ >> > The install image built with build X is obviously built before >> future >> > builds, build X+1, build X+2, ... etc, so it is impossible to >> directly >> > embed into the installer what builds it can support. So this >> > compatibility knowledge must be placed with the packaged install >> > bits themselves. So the proposal here is to create a new package, >> > SUNWinstall_compat, which for each build will define which >> > builds of the installer is able to support installing that build. >> The >> > new package would contain a simple text file with >> > >> > MIN_INSTALL_COMPAT_BUILD= >> > MAX_INSTALL_COMPAT_BUILD= >> > >> > >> > 2.1 Installer changes >> > The installer will be enhanced to download the requested build's >> > SUNWinstall_compat package first, then check that the build it >> > was built with falls within the MIN and MAX value. >> > >> > if (requested build has no SUNWinstall_compat package) >> > WARNING: no SUNWinstall_compat pkg found. Install will >> > proceed, but ... >> > >> > else if (install image build is out of range of MIN and MAX) >> > WARNING: this install image is not supported to install >> > build X. Install will proceed, but .... >> > >> > >> > 2.2 SUNWinstall_compat package >> > The new SUNWinstall_compat package will deliver a text file >> > with the MIN and MAX build numbers defining which builds of >> > the install image are supported to install that build of the >> > packages. This package is not installed on the installed machine. >> > >> > MIN_INSTALL_COMPAT_BUILD=[integer: 0,infinity] >> > MIX_INSTALL_COMPAT_BUILD=[integer: 0,infinity] >> > >> > The MIN_INSTALL_COMPAT_BUILD value needs to be updated >> > only when known Flag Days occur for the Installer installing >> > pkg-based bits. For example, if in build 115, we need to make >> > changes in ICT to support pkg-based installing of build 115, then >> > we update the MIN_INSTALL_COMPAT_BUILD value in build 115 >> > to be 115. Any previous build installer will now emit a WARNING >> > when they pkg-base install bld 115. If we happen to forget to >> > update this file for build 115, its easily back-publishable since >> its >> > just a text file. >> > >> > The MAX_INSTALL_COMPAT_BUILD value should always be left >> > as infinity for new builds. This value is useful only to be >> > backpublished when we know of changes to the installer that >> > prevent it from being able to install some older build. >> > For example, if in build 120, we make changes to the installer >> > such that it can no longer pkg-base install build 111 on back, >> > then we backpublish the SUNWinstall_compat package for builds >> > 111 on back to have a MAX value of 119 (or back until we hit some >> > build that already has a value for MAX) >> > >> > >> > Issues >> > ---------- >> > [2] assumes one shared base of installer tools wrt pkg-based >> > installs. i.e. a LiveCD pkg-based installer and the AI pkg-based >> > installer wouldn't have different installer compatibility >> boundaries. >> > Otherwise separate sets of MIN and MAX values would have to >> > be defined for each pkg-based installer. >> >
