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

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]

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

Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/