Audacity needs a loving family

Tom McLaughlin tmclaugh at sdf.lonestar.org
Sat Feb 24 20:33:18 UTC 2007


On Sat, 2007-02-24 at 08:41 -0500, Peter Beckman wrote:
> On Fri, 23 Feb 2007, Craig Boston wrote:
<snip>
> 
>   I'm not interested in maintainership of Audacity, but your post did bring
>   up a thought.
> 
>   I think it would make sense to have a wiki for maintainers where they can
>   keep notes, documentation and special circumstances information about
>   ports.  Add links to the definitive source of the code, a short history,
>   a link to the CVS/SVN repository changelog, and as Craig mentioned above a
>   listing of "a few issues ... that need to be kept in mind."  This way even
>   if Craig got hit by a beer truck (God forbid), the knowledge Craig gained
>   during his maintainership would live on.  One section per port, and ports
>   could link to eachother (dependencies).
> 

Most of this information can be obtained already from cvs logs if people
take the time to write informative PR descriptions (and we take the time
to make informative commit messages).  I typically cut and paste the
relevant lines from an app's included ChangeLog into commit messages as
well as my own notes now.  I can then use freshports or `cvs log` to
look at my port's history as can anyone else and get a pretty good idea
of what's gone on over time.  I think many other ports committers simply
cut and paste PR descriptions as commit messages too.  There are some
things that are harder to keep track of through cvs logs like known
issues but I don't see anything wrong with maintainers adding a "known
issues" section to a port's pkg-descr.  They can even add an "RCS:" line
to it with a link to the site's code repo if they want.

There are some other alternatives of course.  In the OpenBSD ports tree
maintainers often write their own README or README.OpenBSD for their
ports.  These files are typically open ended and include whatever info
the maintainer deems relevant.  Gentoo uses a ChangeLog file in portage
for each app.  This is in part because each program version has its own
ebuild file so change history is not preserved across program versions
by the ebuild file.  Maybe people might find the addition of an optional
README.FreeBSD or ChangeLog file useful as a coherent record of the port
and maintainer's work?

tom

<snip>

-- 
| tmclaugh at sdf.lonestar.org             tmclaugh at FreeBSD.org |
| FreeBSD                                   http://www.FreeBSD.org |
| BSD#                    http://www.mono-project.com/Mono:FreeBSD |



More information about the freebsd-ports mailing list