[eigen] is there a policy on committing bugfixes to a release branch?

[Mark Borgerding <mark@xxxxxxxxxxxxxx>]

I'm not talking about adding new features on a release branch, but a 
legitimate bugfix.

I have the privilege to commit, and I want to be responsible in its use.

I looked on the wiki, but could not find philosophical guidance as much 
as mechanical advice. Perhaps I missed it in my brief search. In this 
case, I apologize for wasting your time and the electrons required to 
bring the rest of this email to you.  Or maybe this policy doesn't exist 
because good policy on this is hard as it requires good judgement.

Specifically, I found a bug that exists in both 3.2 and default 
branches. I fixed it in default, but I have not yet patched the 3.2 
branch since I don't want to display bad judgment and/or run afoul of 
any best practices we may have. This email is not about this bugfix per 
se, but it was a catalyst for it. More details at the end if you are 
interested. It is a minor bug and one with an easy workaround.  However 
it is not easy to write a test case for it. Testing involves building 
with multiple versions of Intel MKL.  I've tested against 3.

The small question is: Should  I apply this bugfix to 3.2?

The big question is: How far do we go to ensure a release branch is 
always bugfree? This is complicated by the fact that a bugfix can 
inadvertently introduce an ironic new bug -- not this one, of course, 
but you know *other* peoples bugfixes ;) .   Is there a policy or best 
practice that makes the best use of developer resources to ensure the 
quality of the release branches?

Path 1: Quality ensured by "THE PROCESS" (muffled screams)
It would be easy to dream up an elaborate system of checks and balances 
that requires traceability to a confirmed bug report, automated test 
cases, gatekeeper committers, etc, etc.  But this could be a stiflingly 
unrealistic barrier to bugfixes.  As an aside: I consider cmake a big 
barrier to entry for contributors to the project, unfortunately I have 
no alternative to suggest.

Path 2: "Use your best judgement"
At the other end of the spectrum: a lack of review on the release branch 
raises the possibility for ironic bugs. Should a user be able to assume 
the tip of the release branch is absolutely the most stable version? Or 
should they look to tagged versions?  Assuming the latter allows us to 
use the release branch for bugfixes with some confidence that any ironic 
bugs will be found before a tag.


Bug Specifics:
 (changeset f912c18f0267 : "Check IMKL version for compatibility with 
Eigen" ).
The background on the specific bug:  My project is built from source by 
several customers who have various versions of tools.  We defined 
EIGEN_USE_MKL_ALL in our build, but then realized it bombed for 
customers with older MKL versions (#include <mkl_lapacke.h> failed-- no 
such file ).  Rather than force our build system to detect the MKL 
version and conditionally set this flag, I wanted to fix the upstream 
Eigen source.

-- Mark