|[eigen] is there a policy on committing bugfixes to a release branch?|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
I'm not talking about adding new features on a release branch, but a
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.
(changeset f912c18f0267 : "Check IMKL version for compatibility with
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