[ On Monday, January 10, 2005 at 21:34:15 (-0600), James Chacon wrote: ]
> Subject: Re: HEADS UP: XFree86 3.3.6 has been EOLed
>
> I said "XF3" for a reason. The only changes there were adding sh3 support
> (now in XF4 as well) and twm changes. Nothing else is different...

You shouldn't try to confuse me with meaningless/misleading terms.  ;-)

From my point of view there is no "XF3" (or "XF4" for that matter) in
NetBSD.  Those are meaningless and misleading abbreviations that have
much better and more concrete terms/phrases that should be used when
talking about NetBSD sources.

There is xsrc/xc and xsrc/xfree/xc.  Both have the same netbsd-1-6
branch created in them.

Once upon a time it was strongly suggested, if not also stated
concretely in published documents, that xsrc trunk would be supported
for non-EOL src branches such as netbsd-1-6.  However xsrc/xc was simply
removed from the trunk without having its final changes merged to a
supported branch.  That makes it rather difficult for any of us who were
tracking xsrc trunk for platforms that need xsrc/xc in netbsd-1-6.

That's all that I really care about at the moment w.r.t. xsrc.  That's
all that I'm really talking about here.

Originally I was more concerned with the "lost" changes, no matter how
minor, especially if I moved xsrc to the netbsd-1-6 branch.  Howeve now
I realize that what I really want to keep doing is to keep tracking the
whole xsrc trunk for my netbsd-1-6 poduction builds, just as I was
promised I could do.

For what it's worth I would be happy to move to the xsrc netbsd-1-6
branch if that branch were _FAR_ more agressively merged to, and I see
no reason whatsoever why such merging can't or shouldn't be done given
the stated goal of supporting xsrc trunk (-current) for non-EOL src
branches, and especially given that at least one of us can offer patches
to the distrib/sets/lists files to match.  However such merging would
seem to be a waste of effort if there's a better way; and I agree it
would introduce a lot more upheaval to the branch for xsrc than some
other folks might be expecting.

I could try moving just my primary production xsrc/xc working directory
to the netbsd-1-6 branch, but that's not entirely safe and fool-proof
with CVS given that there's no separate module defined for it and no way
to make sane and simple use of such a module in the build system even if
one were to be defined.....

The other "obvious" option would be to undo the EOL of xsrc/xc until
such time that _all_ non-EOL src branches can make sole use of
xsrc/xfree trunk.

(I won't mention one other "obvious" option I've thought about since
it's not something I would want, though in some respects it might be
what I deserve!  ;-)

> No one ever said we wouldn't use XF4 down the road on the branch.

That makes absolutely no sense whatsoever to me.

If I interpret it the way I think it reads then "it" is already used on
the branch, for some platforms.  Are you saying that at some point
xsrc/xc will be removed on the netbsd-1-6 branch too?

In the near future I'm going to want to know if I can avoid Xfree86
device driver security brain-damage for platforms that used to use
xsrc/xc (i.e. which don't need/want the Xfree86 brain-damage), but
that's not my worry yet.  ;-)

-- 
						Greg A. Woods

H:+1 416 218-0098  W:+1 416 489-5852 x122  VE3TCP  RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>