Date: Wed, 18 Jul 2012 10:04:54 -0700 From: Trent Nelson <trent@snakebite.org> To: Trent Nelson <trent@snakebite.org>, Warren Block <wblock@wonkity.com>, Eitan Adler <lists@eitanadler.com> Cc: Matthew Jacob <mj@feral.com>, "freebsd-stable@freebsd.org" <freebsd-stable@freebsd.org>, David Magda <dmagda@ee.ryerson.ca> Subject: Re: The MFC process... Message-ID: <CC2C63FE.32E5F%trent@snakebite.org> In-Reply-To: <CC2C3181.32C29%trent@snakebite.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7/18/12 9:38 AM, "Trent Nelson" <trent@snakebite.org> wrote: >On 7/17/12 2:40 PM, "Warren Block" <wblock@wonkity.com> wrote: > >>On Tue, 17 Jul 2012, Eitan Adler wrote: >> >>> On 17 July 2012 10:10, Warren Block <wblock@wonkity.com> wrote: >> >>>> Unless there was no PR. Which brings up the question of how can we >>>>query >>>> for MFCs now? For example, how many MFCs are past due? What is the >>>>oldest >>>> one? >>> >>> svn mergeinfo --show-revs eligible >> >>But those are just commits that svn sees as eligible for a merge, not >>ones with an actual "MFC after" message. > >Those two concepts should be considered synonymous :-) > >>From a fitting-svn-best-practices-to-freebsd-development-style >perspective, this is what developers should be doing: > >1. If a change is eligible for MFC, obviously indicate that in the log >message as usual. So, no change from how development is done now. > >2. If a change is not eligible for MFC, or should never be merged back to >stable for whatever reason, it should be blocked in such a way that svn >will know never to suggest merging it. > >This would be done as follows: > >% cd /src/head >[make change] >% svn ci -m "..." >Committed revision r890101 >% cd /src/stable/9 >% svn st >[ should return nothing -- I.e. no local mods ] >% svn merge --record-only -c890101 https://svn.freebsd.org/base/head . >... >% svn ci -m "Blocking r890101." . > >If this approach is adopted by all developers -- `svn mergeinfo >--show-revs eligible` will always do exactly what you want: show revisions >eligible for MFC that have not yet been merged. > >You can run this command at any level, too. I did it at sys/dev/isp, >because that's all I cared about, but you can go as deep or as shallow >within the tree as you like. > >It would also be trivial to whip up a script that runs it at the top >level, then for each rev, filter it based on committer. That would >achieve Eitan's desired goal of "tell me all my outstanding head/ commits >I need to MFC". show_outstanding_mfcs() { # usage: show_outstanding_mfcs <username> <path> # e.g. show_outstanding_mfcs mm / # show_outstanding_mfcs mjacob /sys/dev/isp # note: specifying '/' for path is super expensive (on the server) # and slow (for you) -- try and refine it to a finer granularity. # Prints a '.' for each revision it finds if you're not the author, # just to let you know it's still chugging along. local _user _path _user=3D$1 _path=3D$2 local _repo _rev _head _stable _tmpfile _author _repo=3Dsvn://svn.freebsd.org/base _head=3D$_repo/head/$_path _stable=3D$_repo/stable/9/$_path _tmpfile=3D$(mktemp /tmp/$0.XXXXX || exit 1) for _rev in $(svn mergeinfo --show-revs eligible $_head $_stable); do svn log "-$_rev" "$_repo" > $_tmpfile _author=3D$(head -2 $_tmpfile | tail -1 | cut -f 2 -d '|' | sed 's/ //g') if [ "$_author" =3D "$_user" ]; then echo "" cat $_tmpfile else echo -n "." fi done echo "" rm -f $_tmpfile } Sample usage: % show_outstanding_mfcs mjacob /sys/dev/isp ------------------------------------------------------------------------ r227126 | mjacob | 2011-11-06 00:44:40 +0000 (Sun, 06 Nov 2011) | 4 lines Implement the sysctl's for fibre channel that are listed in the man page. MFC after: 3 days ------------------------------------------------------------------------ ------------------------------------------------------------------------ r227548 | mjacob | 2011-11-16 02:52:24 +0000 (Wed, 16 Nov 2011) | 5 lines Was chasing down a failure to load f/w on a 2400. It turns out that the card is actually broken, or needs a BIOS upgrade for 64 bit loads, but this uncovered a couple of misplaced opcode definitions and some missing continual mbox command cases, so might as well update them here. ------------------------------------------------------------------------ ------------------------------------------------------------------------ r228914 | mjacob | 2011-12-27 14:59:24 +0000 (Tue, 27 Dec 2011) | 5 lines Fix target mode compilation issues that arose after a change in the sense data structures. MFC after: 1 week ------------------------------------------------------------------------ ------------------------------------------------------------------------ r237210 | mjacob | 2012-06-17 21:39:40 +0000 (Sun, 17 Jun 2012) | 19 lines Prepare for FC-Tape support. This involved doing a lot of little cleanups and crosschecks against firmware documentation. We now check and report FC firmware attributes and at least are now prepared for the upper 48 bits of f/w attributes (which are probably for the 8100 or later cards). This involed changing how inbits and outbits are calculated for varios commands, hopefully clearer and cleaner. This also caused me to clean up the actual mailbox register usage. Finally, we are now unconditionally using a CRN for initiator mode. A longstanding issue with the 2400/2500 is that they do *not* support a "Prefer PTP followed by loop", which explains why enabling that caused the f/w to crash. A slightly more invasive change is to let the firmware load entirely drive whether multi_id support is enabled or not. Sponsored by: Spectralogic MFC after: 1 week ------------------------------------------------------------------------ ------------------------------------------------------------------------ r237537 | mjacob | 2012-06-24 17:30:54 +0000 (Sun, 24 Jun 2012) | 11 lines Clean up multi-id mode so it's driven by the f/w loaded, not by some hint setting. Do more preparations for FC-Tape. Clean up resource counting for 24XX or later chipsets so we find out after EXEC_FIRMWARE what is actually supported. Set target mode exchange count based upon whether or not we are supporting simultaneous target/initiator mode. Clean up some old (pre-24XX) xfwoption and zfwoption issues. Sponsored by: Spectralogic MFC after: 3 days ------------------------------------------------------------------------ ------------------------------------------------------------------------ r237544 | mjacob | 2012-06-25 03:06:29 +0000 (Mon, 25 Jun 2012) | 4 lines Unbreak register tests for parallel SCSI. You can't overwrite registers 7 and 8. MFC after: 3 days ------------------------------------------------------------------------ Enjoy! (And sorry to pick on Matt, heh.) Trent.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CC2C63FE.32E5F%trent>