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 Fri, 02 Sep 2005 16:05:52 GMT
This all sounds good.  We can call it "recommended practice" rather than 
"policy"  I would agree that in general we can't require anything of 
anyone, but it's also true that there is some level of peer pressure 
involved here -- the "meritocracy" of the Apache Way.  We shouldn't be 
heavy-handed, but we also need to have some level of "process" in place 
so that we can regularly deliver high-quality, high-performance releases 
of Derby.  Right?

David

Daniel John Debrunner wrote:

>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
>>    
>>
>
>While this is a good process, it should not be seen as exclusive. Maybe
>'recommended practice' would be a better term than 'process'?
>
>A fixer may only care about fixing the bug in the trunk, it could be
>someone else who cares about the fix being in a branch and thus performs
>the merge and testing.
>
>A fixer may only care about fixing a bug in a branch, because that's the
>version they are using. There should be nothing in Derby's site that
>prohibits such work. It's better to get the bug fixed somewhere than not
>at all.
>
>In the various recent questions/suggestions about process and other
>related items it is worth remembering this is open source and thus:
>
>  1) people do what 'scratches their itch'
>  2) In general, you cannot require anyone to do anything
>
>Dan.
>
>  
>

Mime
View raw message