db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: Bugs and 10.1.2 release
Date Fri, 02 Sep 2005 18:44:31 GMT
I appreciate the desire to be cautious about  loaded words like 
"process". However, methinks it's worth hammering out "rules of 
engagement" whenever we have to scratch a collective itch. A release, 
for instance, is a collective itch. I think it would be reasonable for 
the Release Coordinator to publish their "rules of engagement" soon 
after accepting the job. The community can debate and amend these rules 
and, if the Release Coordinator doesn't like the conclusion, they can 
resign the post. In fact, the Release Coordinator can resign at any 
point if they feel they aren't getting the community support they need.

It looks like Andrew is being volunteered as the 10.1.2 Release 
Coordinator. If he's willing to perform this task, he can tell us what 
kind of support he expects from the rest of us. We can discuss it.


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

View raw message