db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Satheesh Bandaram <sathe...@Sourcery.Org>
Subject Re: Bugs and 10.1.2 release
Date Thu, 01 Sep 2005 23:13:25 GMT
I am not sure if we should put our general process info on a Wiki.. Are
you proposing effectively moving most of the website info to the Wiki? I
would rather have Jean or some PMC member control the process info and
changes to it. She has been very effective in managing the site so far.
For all other stuff, including coding and architectural ideas/tips, Wiki
is great. Can Wiki have pointers back to website for process info? :-)


David W. Van Couvering wrote:

> 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.

View raw message