Subject: Re: Binary packages available for 2.0
To: Bill Studenmund <wrstuden@netbsd.org>
From: Tim Kelly <hockey@dialectronics.com>
List: port-macppc
Date: 11/22/2004 13:47:01
Hi Bill,
I appreciate you taking the time to clarify these aspects for me. I'm
used to be a solo developer or in environments in which everyone was in
a unique specific area. I'm still getting the nuances of cvs and working
in an overlapping, distributed development environment.

> We can change -current willy-nilly and 2.0 won't be affected.
> Conversely, if we make a change to -current, we have to take special
> steps to cause the change to show up on the 2.0 branch. The 2.0 cycle
> has had a lot more stuff from -current get pulled into it, so it is
> much closer to -current than other releases have been at release. The
> only things that we don't want to pull into a branch are ones that
> will bump the kernel version. We want life on a release branch to be
> much more incrimental than life on -current.

I read the above to say that 2.0 is a subset of -current; there are
things in -current that are in 2.0, but all of 2.0 is in -current. Is
this correct?

What nomenclature is used to denote port specific bug fixes and
releases? Is there a set time frame on when those bug fixes will have a
specific (tag), such as once a month? What about a -bugs branch, which
contains bug fixes for the last tagged release, but doesn't have
everything from -current in it? Some of the bug fixes might be
experimental for a while (like the MP fix, which almost assuredly will
have to have additional debugging info in it along the way), so this
branch might allow users to get known working bug fixes without getting
some "might work" bug fixes that also "might not in a bad way." :-)

thanks again,
tim