Subject: Re: current pulled into release branch
To: Jeremy C. Reed <reed@reedmedia.net>
From: Frederick Bruckman <fb@enteract.com>
List: netbsd-help
Date: 01/10/2001 11:32:38
On Wed, 10 Jan 2001, Jeremy C. Reed wrote:

> I am interested in what is involved in "pulling" fixes and/or improvements
> from the -current branch to the release branch.
>
> What exactly does "pull up" mean? (What CVS commands? What steps? Where
> can I find NetBSD tools that automate some of this?)
>
> Who decides what can be added to the release branch?
> Or, how is it decided to pull up an improvement/fix?

A developer makes a request to release engineering. The request is
almost always approved, though occasionally it may be sent back for
minor corrections, first. Releng may solicit requests, as well. Most
of the nitty-gritty details are described in the following documents,
which are intended for developers:

  http://www.netbsd.org/developers/releng/

It also bears mentioning that the entire process is evolving, and that
NetBSD-1.4.x was the first branch to be handled as described.

> How often are fixes or improvements implemented on the -current branch
> that are never pulled up to the release branch? (Or is all working code at
> some time pulled up to the release branch?)

Exactly what gets pulled up is at the discretion of releng, but one of
the goals is that the application interface (in /usr/includes) remains
consistent, so that programs compiled for NetBSD-1.5.2, say, will
still run on NetBSD-1.5. Major changes are also reserved for the next
major release, so NetBSD-1.4.x will never get softdeps, and will never
lose "nfsiod" and "update"; NetBSD-1.5.x will (likely) never get UBC.

But everything makes it into a release, eventually. Even things that
aren't pulled up to the *last* release will still make it into the
*next* release. At the point when netbsd-1-6 is branched, it will grow
off of (some future) current, so it will have everything that's in
current now.

> Is code ever implemented directly on the release branch, but never on the
> -current branch (or much later on the -current branch)?

No, and current isn't a branch, it's the main trunk. (The distinction
is important. This is why future release branches automatically have
everything that's in current now.)

> Can code be implemented on both branches at the same time? (And if
> so, how?)

It could be committed to current, and then a pull-up requested
immediately. This happens most often right after the branch. In
general, it's frowned upon, and not permitted at all for a mature
branch. If you want it all now, just run current, and deal with the
fact that fixing one thing sometimes breaks something else.

-- 

Frederick