Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 11 Apr 1998 14:02:12 -0400 (EDT)
From:      Tim Vanderhoek <hoek@hwcn.org>
To:        Jun Kuriyama <kuriyama@opt.phys.waseda.ac.jp>
Cc:        Dave Chapeskie <dchapes@ddm.on.ca>, freebsd-ports@FreeBSD.ORG
Subject:   Re: PR's in the queue
Message-ID:  <Pine.GSO.3.96.980411133853.28521I-100000@james.hwcn.org>
In-Reply-To: <352F93C2.D45D22DF@opt.phys.waseda.ac.jp>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.3.96.980411133853.28521I-100000>