db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: Bugs and 10.1.2 release
Date Thu, 01 Sep 2005 21:55:37 GMT
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/%3C4310AA29.8000403@sbcglobal.net%3E
>
>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
>
>
>  
>

Mime
View raw message