On Sun, 12 Dec 1999, Greg A. Woods wrote:

> If one of the goals of NetBSD is really to make a clean and elegant
> *source* distribution for an operating system then . . .[no /usr/src/dist]

Some of what you're saying makes a lot of sense.  I will advance some
counterarguments simply because you haven't mentioned them, but perhaps i
actually agree with you, although only for very small programs.  but, it
is still more important to me that (a) we have the latest version, and (b)
tracking the latest version becomes easier so that it can be done more
frequently without taking time away from real development.

 o /usr/src/dist _is_ clean

   By ``clean'' perhaps we mean something which makes future development,
   maintenance, and comprehension easier.  In many cases, this is somewhat
   reduceable to ``whatever's easiest.''  The package system is a great
   example.  bsd.pkg.mk does not look ``clean'' but it concentrates the
   inevitable dirtyness of packages onto itself, thus making individual
   Makefiles cleaner and shorter, solving common problems once, avoiding
   rework.

   In a less dramatic sense, if dist makes the work of developers who work
   on dist'ed things easier, maybe it is ``clean.''

 o /usr/src/dist makes local patches easier to maintain across imports

   I believe we sometimes make changes in CVS to a source file under dist/.
   I don't get the sense that we hesitate to do so.  If we do, making the
   changes under dist/ instead of in a post-import-script copy means 

    o the changes are easier to send back to the maintainer
    o the changes are easier to roll into the next version, when it comes
      out.

 o dist is easier because it is the most logical build layout for the type
   of development we use it for.

   The easiness can be taken as a consequence of a layout that symbolizes
   the work we do--it divides into separate pieces the Maintenance of
   Foreign Code task and the Coercing of Foreign Code into our Build
   Process task.  These tasks are very different and ought to be
   separated.

   Even if you argue the layout is harder to understand (depending on your
   perspective, it might not be), still at least the CVS histories are
   much more useful for a project that was done with dist, and CVS's 
   usefulness is generally highly dependent on directory layout.

 o at least for the case of /usr/src/gnu/dist, it's a useful tree in
   itself

   The GNU toolchain has a standard build layout of its own, and a lot of
   GNU tarballs will extract into a piece of this common layout.  They are
   trying to do the same thing we are--they're just not doing it as well
   and aren't finished yet.  But, their layout is still well-considered
   and is a worthwhile thing to offer users of our source in itself.

   and then there's the licensing thing, which i'm not discussing further.

-- 
Miles Nordin / v:1-888-857-2723 fax:+1 530 579-8680
555 Bryant Street PMB 182 / Palo Alto, CA 94301-1700 / US