Hi Chris,

On 6 Sep 1999, Chris G. Demetriou wrote:
<snip>
> So, a bit of explanation about the NetBSD release engineering process:
> 
> Patch release binaries, e.g. the NetBSD/arm32 1.4.1 binaries, are
> created from the sources of the patch release.  If the patch wasn't in
> 1.4.1, there's pretty much no such thing as "new 1.4.1 release
> binaries" which will contain it.  There might be additional binaries
> released with the patch, but, by virtue of the patch it wouldn't be
> right to call them 1.4.1.
> 
> Problems like compiler bugs can easily be fixed in subsequent patch
> releases: bug fixes get committed, and then "responsible parties,"
> e.g. the port maintainer, the committer of the bug, or other
> developers who feel themselves competent to do so can request that the
> bug fixes be pulled up to the release branch.  They're then made
> available as part of the release-branch bits up for FTP/SUP, are
> accessable on the release branch via anon-cvs, and, finally, are
> incorporated into subsequent patch releases.
> 
> What this means, really, is that if you've got a PR that's near and
> dear to your heart -- e.g. compiler bug fixes -- which has been solved
> in -current or could easily be solved in -current, you have to poke
> the appropriate responsible parties (e.g. the port maintainer) to make
> sure that the patches get applied and get pulled up to the release
> branch.  Often, this happens without much prodding.  That's "The Right
> Thing."  Other times, it takes more work.

Thanks! I guess I didn't really got that NetBSD x.y.z releases were just
mere patches released in a distribution... I guess the numbering sceme is
just different that I'm used to..

Cheers,

Reinoud