Hi, Kathey, thanks. My apologies if I didn't see this the first time
you sent it out, there's a lot of email on the list if you haven't
noticed :).
I think this makes a lot of sense. Awaiting others to comment, but
otherwise I'll post it (once I figure out where to post it).
David
Kathey Marsden wrote:
David W. Van Couvering wrote:
I am not clear how this has been done in the past: what is the process
for a contributor (who is not a committer) to get their patch into the
appropriate branches? Do we depend upon the version that the bug was
reported in? Should the contributor indicate what branches the patch
should be applied? Is the contributor responsible for testing on each
branch and providing a separate patch for each branch?
This was the process I proposed for 10.1.2
-- Fixer fixes bug in the *trunk*
-- Fixer posts a patch and indicates if if they want the fix in 10.1.
-- Committer commits and objections to port can be raised based on risk.
-- Fixer tests change on 10,1 then posts svn merge command or 10.1 patch.
-- Committer applies the svn merge command and commits to 10.1
More detail is in my original mail at:
http://mail-archives.apache.org/mod_mbox/db-derby-dev/200508.mbox/[EMAIL
PROTECTED]
My thoughts are that by encouraging folks to check into the trunk first and leaving risky changes there, we avoid potential regressions that can be caused by fixes never getting forward ported or inappropriate fixes going to the branch.
As a followon, is there a common place where we can put policies and
procedures like this? There is the Apache Way and the Apache DB
Project guidelines, but I think we need our own. All I see so far is
a link to an email thread about applying patches.
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.
If there are no objections, I'd be happy to get this started. I'd
love to do this on a Wiki so it's easy for anyone to contribute. How
do we feel about doing more stuff on our Wiki and not having to check
everything in through Forrest?
+1 to the Wiki and your offer to get it started. I have content I have
not contributed simply because I have not yet gotten to the learning
Forrest line item on my todo list. Also a Wiki is great for
collaboration and correcting and updating content.
Kathey
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
