Re: [eigen] Bugs on bugzilla

Hi,

so basically we are facing three interconnected problems:

- we have to better structure our community,

- attract more contributors,

- deal with the numerous bug entries.

Regarding the structuration of the community, we could try to lean towards something like:

- a small steering committee taking the major decisions on the evolution of Eigen,

- assign one person in charge for each module of Eigen, each platform, etc. (from regular Eigen's developers)

- assign a release manager taking care of the progress of each feature planed for the next release.

- a pool of reviewers to review novel features (do not need to be an Eigen's developer)

However, I'm not sure that currently we have enough man power to go to such a formal structure.

As Christoph suggested, identifying active contributors with their domain of expertise would already be a good step. Here I'm thinking about "contributors" and "expertise" in a very general way, not only code!

This last remark leads me to the second item (attract more contributors) for which I'd like to emphasise that there are many way to contribute to Eigen without knowing its internal:

- documentation,

- support to other users,

- unit testing,

- fix compiler/platform specific issues,

- discuss API,

- etc.

What about adding a "How to contribute?" page developing these items on the web site? Any volunteers?

Then we need a way to keep track and easily spot these 'junior jobs" which could be addressed without requiring any knowledge on Eigen's internals.

So instead of adding a voting system to the bug tracker, I'd rather add a such a field.

gael

On Mon, Jun 2, 2014 at 11:35 AM, Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:

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
----------------------------------------------