Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <42D2FF8B.40007@debrunners.com>
Date: Mon, 11 Jul 2005 16:23:55 -0700
From: Daniel John Debrunner <djd@debrunners.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
To: Derby Development <derby-dev@db.apache.org>
Subject: Fixing bugs in 10.1/trunk - WAS Re: Client data source issues
References: <42CDAE16.9030001@apache.org> <42CDB1BB.2010404@debrunners.com>
 <42D2A947.6020607@sun.com>
In-Reply-To: <42D2A947.6020607@sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

David Van Couvering wrote:

> Hi, Dan.  Can you describe in more detail the process you are proposing
> here?  It sounds like you are suggesting that when someone does a bug
> fix, it would be great if it were done in the 10.1 branch *and* the trunk?

I guess the basic idea is that if some user reports a bug in 10.1 then
there is some mechanism that allows them to get a Derby 10.1.x.y release
that includes a fix to their problem. The current state of things (in
general) has been bugs have been only fixed in the trunk and therefore a
user has to wait until the next release (several months) to get a fixed
version of Derby.

Now if selected bug fixes were fixed in the trunk and merged up into the
10.1 branch then then users could obviously pick up fixed 10.1 versions
either through snapshots or releases. As for if a specific bug should be
fixed in (merged into) 10.1, that most likely is a case by case
decision, based upon the severity of the problem, the risk of the fix
etc. I do think that changes to the trunk post the initial release do
need to be carefully reviewed by committers and others to ensure that
the quality of the trunk does not degrade.

So it would be great if a developer fixed a bug in the trunk and then
even better if they were willing to merge it into 10.1. Such merging
should not be seen as a requirement though, it's all down to "scratching
their own itch".

Anyone who wanted to see bug fixes from the trunk moved into 10.1 could
also offer to help merge changes from the trunk to 10.1, and then help
in getting a newer 10.1 release generated.

Related to this I would like to see a way to mark a fixed bug as 'this
is a good candiate for 10.1 as well', e.g. DERBY-447. Anyone looking to
produce an improved 10.1 could use such a list of bugs to select ones to
merge to 10.1 branch.

Dan.