freebsd stable - Jul 2012 - The MFC process...

There are currently no automated MFC systems in place, correct?  I.e. the
onus is completely on the developer that made the change to head to merge
back to stable?  Do the RELENG team do anything in particular to check
that changes for MFC actually make it back to stable?

Reason for asking, I noticed a bit of disparity between dev/isp between
head and stable/9:

% svn mergeinfo --show-revs eligible \
 svn://svn.freebsd.org/base/head/sys/dev/isp \
 svn://svn.freebsd.org/base/stable/9/sys/dev/isp
r227126
r227548
r228914
r237210
r237537
r237544
r238486

I'm currently running a local tree with those revs merged in manually
(simply via `svn merge svn://svn.freebsd.org/base/head/sys/dev/isp .` in
/usr/src/sys/dev/isp), but it'd be nice to get them into 9.1, as they're
all past their recommend soak time (except for that last one, which is a
typo fix).

Anyway, that got me thinking about the MFC process, especially leading up
to another release, hence this e-mail.  What's the preferred way for
non-committers to bring outstanding MFCs to the attention of committers?

Regards,

	Trent.

On 16 July 2012 19:33, Trent Nelson <trent@snakebite.org>
wrote:
>
> There are currently no automated MFC systems in place, correct?  I.e. the
> onus is completely on the developer that made the change to head to merge
> back to stable?
Correct.
> Do the RELENG team do anything in particular to check
> that changes for MFC actually make it back to stable?
As far as I am aware, they do not.
> Reason for asking, I noticed a bit of disparity between dev/isp between
> head and stable/9:
>
...
> I'm currently running a local tree with those revs merged in manually
> (simply via `svn merge svn://svn.freebsd.org/base/head/sys/dev/isp .` in
> /usr/src/sys/dev/isp), but it'd be nice to get them into 9.1, as
they're
> all past their recommend soak time (except for that last one, which is a
> typo fix).
We are currently in a code freeze for 9.1 so no unapproved MFCs may be
committed.
> Anyway, that got me thinking about the MFC process, especially leading up
> to another release, hence this e-mail.  What's the preferred way for
> non-committers to bring outstanding MFCs to the attention of committers?
Exactly the way you did it here: a polite email. :)

-- 
Eitan Adler