From owner-freebsd-ports Sat Apr 11 11:09:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA10617 for freebsd-ports-outgoing; Sat, 11 Apr 1998 11:09:47 -0700 (PDT) (envelope-from owner-freebsd-ports@FreeBSD.ORG) Received: from hwcn.org (ac199@james.hwcn.org [199.212.94.66]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA10612 for ; Sat, 11 Apr 1998 11:09:46 -0700 (PDT) (envelope-from hoek@hwcn.org) Received: from localhost (ac199@localhost) by hwcn.org (8.8.8/8.8.8) with SMTP id OAA15100; Sat, 11 Apr 1998 14:02:12 -0400 (EDT) Date: Sat, 11 Apr 1998 14:02:12 -0400 (EDT) From: Tim Vanderhoek To: Jun Kuriyama cc: Dave Chapeskie , freebsd-ports@FreeBSD.ORG Subject: Re: PR's in the queue In-Reply-To: <352F93C2.D45D22DF@opt.phys.waseda.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 12 Apr 1998, Jun Kuriyama wrote: > Should we cross-checking new ports' submissions from other person? > And then follow up PRs like "I check this port and it seems fine." or > "This port does not satisfy portlint." YesYesYesYes! I am not a good port committer for the current situation --- my preference is to check the port (incl. patches) carefully and be somewhat pedantic. What we really need are hordes of testers who are less concerned about making a port perfect, as with making it work. If X committer sees someone's second opinion that X port works, then they feel much safer just shoeing the changes in. Not only that, but it's also an excellent chance to show that you do actually know what you're doing. :-) There are port submitters who, I'm sure, know more than enough to handle reviewing and committing ports, but this is way to prove it more loudly. :) Ideally, this is what should be done... 1) The Makefile should do things simply and reasonably... If you can make it a couple lines shorter, or more readable, then do so. (eg. don't use a shell "if" construct when it can be done with a make ".if" construct, don't use a do-extract if it can be done by redefining ${EXTRACT*}). 2) The patches should be reasonable. If they should be submitted to the program's maintainer (as many should), then the port submitter should be contacted to check if this has been done. 3) Should definately pass portlint. 4) Tested to make sure it actually works. Both that the resultant program runs, and that it passes the "make package", delete package, re-install package, etc. tests. 5) Any bogons, such as CFLAGS, PREFIX, etc. should be fixed or handled appropriately. In general, the port should be checked against your vast (of course! :) knowledge of the proper procedure (eg. docs are included, pkg/DESCR, pkg/COMMENT done well, licenses are unnecessarily copied (eg. we don't need more copies of the GPL in sitting around). 6) The Makefile should conform to the same style as bsd.port.mk. 7) Any legal issues should be noted (eg. don't let the committer forget to fix ports/LEGAL, don't let us illegally distribute software). 8) Just in case the previous points didn't cover them, dependencies, catagories, etc. should be checked. Any appropriate comments (eg. "This should also work with Tcl42") should be added to the Makefile. 9) If the port submitter isn't already listed in docs/handbook/[do-we-have-a-language-code-here-now]/submitters.sgml, then make a note of that so that the comitter doesn't forgot to add the submitter here, as sometimes happens. 10) Anything I've missed should be done. :-) A few of these things could be done automatically. For example, if Satoshi's (or Justin's or David's) package-building machine were to have something like "-yes-this-port-includes-cflags" added to their CFLAGS and cc modified to reject any requests that don't include this special flag, any ports not respecting CFLAGS could be found quickly. -- Outnumbered? Maybe. Outspoken? Never! tIM...HOEk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message