Garrett D'Amore wrote:
>> These changes are not binary incompatible with the Nevada PCRE. There
>> have been no API changes.
>
> As a general rule for ARC, if the last two statements are true, then I
> don't think you need to come to ARC. These are just bug fixes.
The "guideline" is:
I need a review - what do I do?
<strong>Don't panic</strong>
OK, so someone told you that you need an "ARC Review".
This should help you determine what this requirement
really means to you and your project.
The first question is usually "What kind of review do I need?"
* None (Self Review)
Existing projects that
+ have had an earlier case approved by an ARC,
+ do not introduce new interfaces visible outside their own project, and
+ do not alter any interface visible outside their own project
usually qualify for self review and automatic approval.
Most bugfixes qualify for this level of review.
* Fast-Track
A lightweight process for simple cases whose architectural impact
is obvious, and that are not likely to be controversial.
Projects suitable for a fast-track review generally apply
"common practice" in a frequently-performed change or addition.
Projects that set precidents that cross ARC/technology
boundaries may be automatically derailed to cause an opinion
to be generated.
+ The fast-track process assumes you have found a sponsor who
will help you write up your proposal and present it to the ARC.
+ If you don't have a sponsor, you can initiate the full ARC
review process. However, doing so may add up to a week's delay
to your case, and you still must find a sponsor for your case
if you wish it to be treated as a fast-track.
The fast-track process is primarily handled as email discussions
and can take as little as a couple of weeks time to complete.
* ARC Review
If you don't qualify for any of the above shortcuts, you will
need to follow the full ARC review process.
You start the ARC review process by emailing a one-pager
project description
The full ARC review process involves a combination of email,
detailed project specifications, and formal meetings. The
time required varies considerably, but teams should schedule
reviews early - an inception review by mid-prototype stage,
with commitment reviews between alpha and beta in order to
allow the iteam time to incorporate any ARC required changes
before integration.
