Re: xmltools status and (future) integration into base

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Fri, Aug 14, 2009 at 06:22:13PM +0100, Alistair Crooks wrote:
> On Fri, Aug 14, 2009 at 10:48:08AM -0400, Thor Lancelot Simon wrote:
> > On Fri, Aug 14, 2009 at 10:10:36AM +0200, Martin Husemann wrote:
> > >
> > > Since they are interesting for other parties as well, there should be a
> > > pkgsrc pkg for them.
> > 
> > Sure, but that doesn't answer the question of where they should live in
> > the NetBSD source tree.  The point of these tools was to make dealing
> > with XML in the base system easier.  I think they should go in src,
> > where it's simplest for other developers to work on them.
> 
> I've been using src/external/bsd for netpgp and the iscsi code - it
> makes it easier for me to have the portable autoconf-ed source under
> the dist directory in there, to make package releases out of there,
> and to use reachover Makefiles at the same level as dist for our own
> tree.
> 
> I don't know if anyone else likes my doing things this way, and it's
> definitely not the way src/external was envisaged when it was first
> set up, but I really like it.

I have two concerns:

1) Autoconf tends to make the individual source files dirty with large
   numbers of ifdefs, and to yield creeping rot in the BSD reachover
   Makefiles.  These can both be avoided but if we make this kind of
   source integration the norm, I fear they generally won't be.

2) It can be wickedly difficult for a third party to update source
   integrated via reachover makefiles in the best of cases.  It may
   seem that if you "own" these sources yourself, that is no problem,
   but then again we've had developers who were doing precisely this
   disappear before -- see libevent -- and then the code they had been
   maintaining becomes fiendishly hard to manage.

There are clearly pluses and minuses to doing it this way.  One thing
to consider is that the pluses, in terms of administrative nuisance of
dealing with version control, are basically all for the individual
developer who checks in the code this way, while the minuses will fall
on all the _other_ NetBSD developers.  That is not a good thing and
needs to be carefully balanced against any benefit in development pace
or flexibility that this approach may yield.

I didn't bring any of this up before because you didn't ask. :-)

Thor