Re: CVS commit: src/distrib/notes/common

[Pavel Cahyna <pavel%NetBSD.org@localhost>]

On Mon, Oct 01, 2007 at 09:23:56AM +1000, Daniel Carosone wrote:
> On Sat, Sep 29, 2007 at 12:16:36PM +0000, Pavel Cahyna wrote:
> > We would like to have the -current release notes describe netbsd-4,
> > so we can synchronize the netbsd-4 notes completely from -current.
> 
> As a general observation, this seems very wrong to me.  Documentation
> in a branch (incl mainline) should describe the software in that
> branch.  We want to encourage/mandate that documentation be updated to
> match as the code changes are made, and this means your ability to
> make changes in one branch depends on the status of another branch.

I would like to encourage/mandate it for netbsd-5 too, but it simply did
not happen for netbsd-4.

And BTW the list of changes which is one thing that should be updated as
changes are made is not maintained in src/distrib/notes but in
htdocs/releases. If you want to update it for 5.0, just to make a new
subdirectory there and start working on it.

> > If you have updates which don't apply to netbsd-4 please wait until
> > the release...
> 
> No criticism implied at all, but this clearly illustrates my point: it
> would mean that nobody could have updated release notes for 5.0 in the
> past year.
> 
> I know what you're trying to do, and the fact that nobody has made
> such updates means that the current release notes can, in practice and
> "by accident", be synced in bulk as you describe.  I just want to be
> clear about not setting this kind of precedent or policy in general.

The problem is that the 4.0 release notes weren't up to date at all when
the branch was branched. If we were working on them on the branch,
-current would not have the updates, which would make producing ther
release notes for 5.0 more difficult. In fact, that's what happened in
netbsd-3, where the notes were updated only on the branch and now I had
to reapply many typo fixes etc. to HEAD again.

The policy will depend on if we avoid having obsolete release notes
in the future. Of course the current scheme is not ideal, but if the
general attitude towards updating the release notes stays the same, we
will probably set this kind of policy, because it is simply the most
practical.

Pavel