Date: Tue, 17 Jul 2012 01:44:13 -0700 From: Trent Nelson <trent@snakebite.org> To: Eitan Adler <lists@eitanadler.com> Cc: "freebsd-stable@freebsd.org" <freebsd-stable@freebsd.org> Subject: Re: The MFC process... Message-ID: <CC2A9B78.327D2%trent@snakebite.org> In-Reply-To: <CAF6rxgm9gyY936VO9Fc%2B19vcfs8vsbMYC_LW0jxgpvSP==j-Cg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7/17/12 2:10 AM, "Eitan Adler" <lists@eitanadler.com> wrote: >On 16 July 2012 22:35, Trent Nelson <trent@snakebite.org> wrote: >> On 7/16/12 11:19 PM, "Eitan Adler" <lists@eitanadler.com> wrote: >> >>>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. >> >> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CC2A9B78.327D2%trent>