cvs commit: src UPDATING src/sys/netgraph netgraph.h ng_message.h src/sys/netgraph/bluetooth/include ng_btsocket.h

[Eivind Eklund]

On Fri, Aug 20, 2004 at 05:54:26PM +0300, Ruslan Ermilov wrote:
> On Fri, Aug 20, 2004 at 01:14:54PM +0000, Eivind Eklund wrote:
> > On Fri, Aug 20, 2004 at 08:38:59AM -0400, Ken Smith wrote:
> > [... stuff about when MFC becomes "normal" again ...]
> > 
> > I suggest replacing "MFC" with "MT4" (merge to 4.x) and "MT5" (merge to
> > 5) for the case where we are indicating planned merges.  We regularly
> > get into the situation where we have several branches to merge to, and
> > the MFC terminology is quite limiting.  MFC was introduced as a tag used
> > in commit messages when the merge was being done, and the "MFC after"
> > usage was a natural evolution at a point where any non-RELENG_4 MFC was
> > a quite special case.
> > 
> Changing to this would lose the "from" information, which is quite
> useful, as we sometimes merge not only from -CURRENT.

I meant for the markers we put into the commit messages for the
reminder script, and that's explictly from the branch the change
is commited to.  In commit messages where we DO a merge, I think
saying e.g. "MFC: Fix spelling (rev 1.13)" is all good.

> If it's about to change, I suggest using the following template:
> 
> 	MFC [into <branch>] (after|in):

I see some slight disadvantages: It is more to type, and
it include information (that this is -current) that is both
unnecessary (it is known from the ids) and may be wrong if
we change release engineering practices.  Perhaps allow "Merge" as
a synonym for "MFC" (at the risk of even more typing, but being
able to use reminders for other kinds of branches).

I personally also have a fondness for the flexibility in explict
branch names.  I just thought people would want less to type.

If people want this and somebody point me at the reminder script, I'll
cook up patches.

Eivind.