| Re: [eigen] Bugs on bugzilla |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
Hi all!
On 29.05.2014 19:30, Mark Borgerding wrote:
I agree with JItse's characterization that bugzilla has many "feature
requests that no developer is really interested in", and "bugs on
exotic platforms".
I think for both we should introduce some modus operandi that helps us
dropping bugs (or somehow mark them as "known issues" but filter them
out in the "open bug" list). E.g., I would say that we limit "full
support" to compilers still in use (or at least available) by some
(core-) developer. Of course, we should (as much as possible) stay
standard compatible and do not rely on features that just happen to be
achievable in the "main compilers" (e.g., vectorization and alignment
shall always be optional). But I would not like to maintain workarounds
for every buggy compiler which is available somewhere.
Nonetheless, we should make it easier for people using "esoteric"
compilers/systems to fix Eigen and make it compatible -- preferably the
goal should be to have them supply patches and run unit-tests on a
regular schedule.
As for feature requests, I think some kind of voting system would be
nice. Does someone with access to our bugzilla-server know how to set
this up?
For most core-feature requests (e.g., input-stream support (bug 622),
matlab-style submatrices (bug 329)) we require some discussion first,
because here multiple contradicting approaches exist.
Adding to Kolja's ideas: How about a tutorial aimed at Eigen *internal*
developers? e.g. Walk a user through a truly simple, developer task in
the span of a half-hour. Maybe create a algorithm for something that is
understandable and easy to code. Gram-Schmidt or Power Iteration come to
mind. I'd stress that the cmake test environment is not necessary, at
least for beginners.
I would not focus too much on adding new rarely needed features at
first. Most likely this ends up with more work of the core team
supporting the implementer than it will help anyone.
Also, many algorithms look very simple if implemented completely
textbook-style, but are rather complicated to make numerically stable
and handle degenerated cases well. I think this is the case for both
Gram-Schmidt and the Power-Method (and I also think, both are rarely
required).
We already have a bunch of semi-complete modules in our unsupported
category, that might help people who require exactly the parts which are
implemented but there is neither any guarantee how well these work and
the burdun for people who want to enhance these modules is still quite
high -- and I don't think it will get much better by only simplifying
the process to make further new modules.
Furthermore, I do think it is important, especially for new features, to
have them properly documented and unit-tested!
Actually, adding unit-tests and enhancing the (external) documentation
might be the task with the smoothest learning curve.
Musing on the "Drake Equation"-type probabilities -- the intersection of
circumstance, knowledge, and skills needed to be a truly effective Eigen
contributor (a set in which I am not an element) is very small indeed.
1. desire to help
2. time to help ( this is my greatest obstacle in the last few years )
3. Linear Algebra skill : high to expert
4. C++ skill: expert level ( comfort with metaprogramming, partial
specialization, etc) <-- I suspect this shrinks the most!
5. amenability to (possibly new) tools: CMake, mercurial, and
doxygen-style commenting.
I guess that should be the very first task, to get an overview of
"resources", i.e., who is capable and willing to implement or review
patches? Or even just wants to take part in discussions about API
enhancements (such as the above mentioned bugs 622, 329).
For that matter, I don't even have an overview who else has write access
to our main repository, i.e., who would technically be able to accept
patches and pull-requests.
After that, I think the next important step is to prioritize (or delete)
and delegate existing feature requests.
Cheers,
Christoph
--
----------------------------------------------
Dipl.-Inf., Dipl.-Math. Christoph Hertzberg
Cartesium 0.049
Universität Bremen
Enrique-Schmidt-Straße 5
28359 Bremen
Tel: +49 (421) 218-64252
----------------------------------------------