Hi, folks.
Our schedule calls for us to create our release branch this Wednesday, 3
March. Trunk will remain open for forward development, but all changes to
the release branch will require approval.
I'd like to enlist your help with the approval process. When a potential
fix comes in, it needs two forms of review:
1. Review by someone who focuses on the release goals and schedule
2. Review by someone (other than the author) who knows the code being
patched and can speak to the change's significance and safety
My job is item 1. For item 2, I need experts in the various components of
qpid.
So here's my proposal: approval of kinds 1 (from me) and 2 (from someone
familiar with the code being changed) must be indicated in jira comments
before a change may be committed to the release branch.
In order to this efficiently, we need clear lines of responsibility. I'd
like to use the (still emerging) list of component owners to map incoming
changes to reviewers.
In cases where the patch submitter is also the component owner, I'd ask
that he or she find someone else with equivalent experience in that code
to evaluate the change.
The purpose of requiring approval is to ensure that, as we approach
release, each change is *discussed*. I am continually impressed with how
simple questions can lay bare important deficits.
I don't expect this to be a big burden, though I am conscious of the extra
coordination involved. I'll do my best to respond to change requests
promptly.
Here's what I have so far for component owners:
C++ clustering Alan
C++ client and broker Gordon
Java client Rajith
Java broker Robbie
QMF Ted
I just scanned that out of the "Default assignees" thread. Please reply
on this thread if you'd like to volunteer to review changes for a
particular component.
Thanks,
Justin
---
https://cwiki.apache.org/qpid/010-release.html
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
