From owner-freebsd-stable@FreeBSD.ORG Tue Jul 17 08:44:17 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18AE91065670 for ; Tue, 17 Jul 2012 08:44:17 +0000 (UTC) (envelope-from trent@snakebite.org) Received: from exchange.liveoffice.com (exchla3.liveoffice.com [64.70.67.188]) by mx1.freebsd.org (Postfix) with ESMTP id E87F48FC0C for ; Tue, 17 Jul 2012 08:44:16 +0000 (UTC) Received: from exhub13.exchhosting.com (192.168.11.122) by exhub11.exchhosting.com (192.168.11.109) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 17 Jul 2012 01:44:16 -0700 Received: from EXMBX10.exchhosting.com ([fe80::9c37:32f6:a508:a44f]) by exhub13.exchhosting.com ([::1]) with mapi; Tue, 17 Jul 2012 01:44:16 -0700 From: Trent Nelson To: Eitan Adler Date: Tue, 17 Jul 2012 01:44:13 -0700 Thread-Topic: The MFC process... Thread-Index: Ac1j+Fh7WmAn1n/HQBKLNJW78yF+aQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-stable@freebsd.org" Subject: Re: The MFC process... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 08:44:17 -0000 On 7/17/12 2:10 AM, "Eitan Adler" wrote: >On 16 July 2012 22:35, Trent Nelson wrote: >> On 7/16/12 11:19 PM, "Eitan Adler" wrote: >> >>>On 16 July 2012 19:33, Trent Nelson 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. >> >> Sounds like a "what-hasn't-been-MFC'd-back-to-stable-yet" script could >>be >> quite useful, then ;-) > >Of interest to me: if it could be limited to just the commits I made >and optionally show me the log message and diff it would be very >helpful. Agreed. >On a general note: be careful with any level of automation with this >script though. Yeah automated merging certainly shouldn't be attempted in the first cut of the script. (Although the svn-dev@ guys have a post-commit hook that automatically merges changes once three +1's have been registered for the change in CHANGES -- so it's not impossible.) > Sometimes there are good reasons that a commit wasn't >MFCed. Indeed. Technically, commits against head that shouldn't ever be merged back to stable should be marked as such via svn merge --record-only back on the stable branch. (It's a shame how unwieldy the record-only command ended up -- the pre-1.5 svnmerge.py did a much better job: `svnmerge.py ignore r1012098`, `svnmerge.py avail`.) [1] should probably be amended to state that. The advantage of using --record-only to block merges is that `svn mergeinfo --show-revs eligible` becomes infinitely more usable. (And again, that's another terribly unwieldy command; the svnmerge.py equivalent was literally `svnmerge.py avail`.) Trent. [1]:=20 http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/subver sion-primer.html