Hi, Satheesh. I don't think I understand the motivation for keeping
things that don't change frequently on the website. Is it because the
website is more readily accessible? Perhaps if we start using the Wiki
more we should provide a link to it from the website so that it becomes
more accessible too. All things being equal I'd like to keep all our
processes and policies in a single place rather than divided between the
Forrest web site and the Wiki, or at least keep what's on the web site
to a minimum since it really is a more static and harder to update
environment than a Wiki.
David
Satheesh Bandaram wrote:
Some of these questions are also answered in the website... like how
to submit a patch. May be we could use the WIKI to maintain
architectural/coding issues, while keeping the website upto date for
general process info that doesn't change frequently. Coding issues
could include how to add a new error message, adding new service, new
datatype, new builtin functions that can be updated easily in our WIKI.
Satheesh
Daniel John Debrunner wrote:
David W. Van Couvering wrote:
Things I'd like to see described here include:
- How to submit a patch
- How to test a patch
- The issue I'm discussing here about what branches to apply patches to
- Our recommended criteria for a release
- Architectural policies like how to create a new service, how to use a
service, how to work with shared code (if/when we do this), how to throw
exceptions, etc.
Sounds good, most of this has been covered in e-mail discussion, and
thus is in the archives. The trick is finding someone willing to spend
the time to extract it and format in some useful, readable format.
Dan.
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
