From owner-cvs-all Wed May 27 23:17:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA09475 for cvs-all-outgoing; Wed, 27 May 1998 23:17:50 -0700 (PDT) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA09467; Wed, 27 May 1998 23:17:43 -0700 (PDT) (envelope-from jkoshy@FreeBSD.org) From: Joseph Koshy Received: (from jkoshy@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id XAA20115; Wed, 27 May 1998 23:12:06 -0700 (PDT) Date: Wed, 27 May 1998 23:12:06 -0700 (PDT) Message-Id: <199805280612.XAA20115@freefall.freebsd.org> To: cvs-committers@FreeBSD.ORG Subject: Re: doc/FAQ admin.sgml or ``Plan of Action on PRs'' Cc: phk@FreeBSD.ORG, steve@FreeBSD.ORG Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk Hi All, I was afraid that I'd step on someone's toes when closing PRs and it looks like Doug was the first inadvertent victim :(. I totally forgot that the FAQ was being handled by Doug now, not Jordan. Perhaps an explanation to -committers of what I'm planning to do in the next few weeks, and how I'm going about it, is overdue: >>>>>>>><<<<<<<< I'm hoping to run through the PR list, assisting Steve and PHK (our current PR-meisters) in reducing the PR backlog. My target is one PR fixed per day. Here's how I'm proceeding to fix stuff: 1. If the fix is trivial and has no security implications, I just checkin the fix straightaway. Eg:- a one line change to Makefile, doc fixes etc. Less noise on the lists, the better. 2. Otherwise, I run the fix by the "owner" of the area. If I don't remember who the "owner" is, I run it by whoever touched the files last :). If I don't get any feedback (the normal case :(), depending on my confidence level, I plan to either check it in, or post the fix to -current for public review. 3. Fixes go in after testing. This generally means a successful build/install/simple-hand-test for code, and visual inspection and/or racking my brains for Strunk&White's rules for docs. If there's a ready made test suite to run, I will, of course, try to run that. This means that I can't close PRs dealing with environments I can't duplicate, eg:- sophisticated AMD setups, NIS+, NFS stuff etc. There are, unfortunately, quite a few of these. 4. I'm mostly looking into PRs that have no committer "owners". So if you've taken a PR in your name, its (ordinarily) safe from me :). 5. Moving to -stable: generally after a week of stay in -current, unless someone specifically asks for something different; a bit faster for doc changes. 6. If I find a PR that was fixed in the source, but the PR itself is open, I close the PR (administrative change). Steve (I think) has a nice practice of marking the subject line with ``MFC'' to indicate that a merge to -stable is pending. If there is any indication in the PR text that a PR should be kept open, I'll leave it alone. 7. I'm not looking at Ports PRs. >>>>>>>><<<<<<<< These are the rules I hope to follow. If any of you folks have any suggestions/objections/feedback please do get back to me. Till then, Regards, Koshy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message