Indeed Chris's recipe is right and when I've upgraded from 
pre 1.0 to 1.0 to 1.1 to 1.2 to 1.3, I've played this game.

But it does discourage me from picking up new releases especially
intermediate releases, because I have a lot of local diffs and
merging the patches into my tree is never trivial.

So I have a question.  Is there a policy about what goes into
a point release, how often they are made, when releases come out,
etc.  When I upgrade, I have a lot of machines to upgrade (~40)
so I don't want to upgrade w/o good reason.  Consider 1.3.1, I
was hoping that it would have some pcmcia improvements that were
in -current, the MBR id change (165->169) and some of Jason's
changes.  It didn't.  And looking at
	 ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-1.3.2/CHANGES-1.3.2
It doesn't appear that the changes are here either.  So I have to
think hard as to whether I want to upgrade to 1.3.2

So my real question is how about having a serious quarterly release
schedule that includes all features that have been stable for xxx
months before the release (xxx == 1 or 2).



"Chris G. Demetriou" <cgd@pa.dec.com> writes:

> > I am not sure, if it would be a good idea to have two diffs:
> > - one with the security patches in
> > - one without, as there are people who follow the cert lists a bit.
> 
> I don't think so.
> 
> My personal opinion: If you patch your source tree, you take
> responsiblity for making it work (including making future patches
> apply cleanly to it).
> 
> Were I keeping a local source tree for 1.3.x, and applying local
> patches, i'd do something like:
> 
> 	cvs import the 1.3 sources
> 
> 	apply patches on the trunk
> 
> 	try to cvs import the 1.3.1 sources, discover there wasn't a
> 	complete set, send hate-mail off to the NetBSD developers.
> 
> 	import the 1.3.2 sources
> 
> 	merge with the previous vendor branch import (i.e. to merge
> 	patches, etc.)
> 
> 
> I can't address your other concerns, though (e.g. the missing
> files(?)), since i've not as much as looked at the patch.  8-)
> 
> 
> cgd