At the hackyInstaller code review, we had a lively discussion about where
the installer code should end up.

I maintained that the "core" of hackyInstaller was part of the kernel, and
that this part of the system had be logically "below" the standard
extensions to maintain layering.

Others seemed to feel that the installer was an independent application and
had no business co-existing with the kernel code.

I have a compromise proposal:

(1) the 'core' installer code will be in org.hackystat.kernel.installer.
This maintains the layering.

(2) the 'core' installer code will be physically located in a new module
called hackyInstaller (for now, it's hackyInstaller2, but after integration
it will revert to hackyInstaller).  The build dependencies will be altered
so that everything depends upon hackyInstaller as well as hackyKernel.

This feels reasonable to me.  This has the bonus of providing an easy way
to distinguish metrics on future maintenance of the installer code from
maintainence on the rest of the kernel via a top-level workspace.

Comments?  Flames? :-)

Cheers,
Philip

Reply via email to