Date: Wed, 27 May 1998 23:12:06 -0700 (PDT) From: Joseph Koshy <jkoshy@FreeBSD.ORG> To: cvs-committers@FreeBSD.ORG Cc: phk@FreeBSD.ORG, steve@FreeBSD.ORG Subject: Re: doc/FAQ admin.sgml or ``Plan of Action on PRs'' Message-ID: <199805280612.XAA20115@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
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 <jkoshy@freebsd.org> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805280612.XAA20115>