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.
Cheers,
-Rick
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.
