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
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to