Audacity needs a loving family

[Garrett Cooper]

Tom McLaughlin wrote:
> 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>

Either that or a common resource where the maintainer could submit 
changelogs and then users can look up the info... maybe a changelog 
feature on the FreeBSD ports site?

-Garrett