[ On Sunday, December 12, 1999 at 14:10:27 (-0700), Miles Nordin wrote: ]
> Subject: Re: src/dist is a *bad* idea (was: New IP Filter v3.3.5 is now in  the tree)
>
> 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.

This isn't actually true in the long run, especially with the approach
currently being demonstrated.

>  o /usr/src/dist _is_ clean

Of course it is, but that doesn't help those of us who actually use the
*source* product of NetBSD.  It in fact hinders us.  It doesn't really
provide anything that a simple tag in the source tree wouldn't equally
offer.

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

Actually, no, it doesn't necessarily.  It may give that impression
initially, but eventually it will break down and become just as
difficult.

>    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.

If these things are actually that important then the product should be
completely removed from the main source tree and moved entirely to
pkgsrc where local changes are completely and totally separated from the
third party code 100% of the time.

If there's some compelling reason to integrate the product into the main
source tree then it should be done completely and properly.

Simply copying in the new files from a vendor release, committing and
then tagging them, makes it trivial to identify, and roll forward, any
local patches to those files.  Even if the vendor branch stuff wouldn't
get in the way there are other issues if files are moved around first or
after with the *2netbsd script, especially if there are local files
too.  The manual tracking and merging really isn't any more difficult --
just different.

Indeed I've noted that there is apparent hesitation on the part of
developers to change files in src/dist (or at least src/gnu/dist), yet
there is little if any hesitation to changing properly integrated
sources.  I don't know why this is, or if developers even notice it
consiously.

(BTW, I've found in my experience with upgrading packages that it's
usually easier to simply move all the old patches to a standby location
and then manually apply just those that are still necessary, as well as
manually create new ones as necessary.  Also except in very rare
circumstances I've found CVS to be effectively useless, if not indeed
counterproductive, in helping with this process.)

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

This is also not true.  Proper integration provides this ideal logical
build layout while at the same time avoiding the extra obfuscation of
vpath build mechanisms.  It also makes debugging easier if you have to
do your debugging in different source trees (yes gdb can reach over and
use the same source, but only if that source is in the same relative(?)
location).

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

While it might be helpful to segregated licensed code, it's just as easy
(and perhaps more sensible) to create a system that would allow the
creation and maintenance of lists of files falling under given
licenses.  Such lists would make it just as easy for the user to
leverage common effort on such identification while at the same time
avoiding the segregation that makes developers lives harder.

The segregation of licensed code might potentially make it easier for a
third party "user" to install replacement code where they had to avoid
the original.  However I doubt this is really of any benefit except in
the case where the user is able to negotiate a separate license for the
exact same code.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>