Re: [eigen] Bugs on bugzilla

[ Thread Index | Date Index | More Archives ]

On 11.06.2014 08:35, Hauke Heibel wrote:
I wanted to bring up the pull-requests once more. I think we need a simple
policy to decide who may (not from a technical point of view) merge

Simple bugs and compiler fixes are probably the most simple ones for
merging but how about new features (either in core or unsupported) let
alone changes affecting the API. Maybe we can categorize depending on the
new "Severity" classes?

Yes, we need to clarify that. I often see bugs/feature request which I would categorize as either "sure, why not" or "who would need that?" but where I'm quite sure that the opinion might differ. Usually, I don't like to send a mail for each bug to the mailing list like "any objections to accepting patch of bug ...?" -- after all communication about bugs is what bugzilla is intended for. However, discussions on bugs are read by very few persons ...

At the moment I only merge fixes of obvious bugs and reject some bug reports which are, e.g., based on misusing Eigen.

About the remaining 300+ bugs: I would suggest that we (==whoever wants to participate) walk through all of them once and either decline them, or assign them to one of the volunteers (or if possible give them the JuniorJob tag), or change the status to DECISIONNEEDED.

For new bugs, we either need to do this on a regular basis, or we need clear responsibilities (maybe per module?). Alternatively, we could add a new bug status "Confirmed" for bugs which we (or at least one "main" developer) admit need fixing -- or we let new bugs start as "Unconfirmed" and change them to NEW once acknowledged as valid bug.

To decline a bug/feature request, I would suggest that the first one who wants to decline it writes a comment, describing why to decline it and any second person either agrees and closes the bug or disagrees and sets the status to DECISIONNEEDED (preferably with arguments for accepting). Actually, the first person could directly close it (with a reason), and anyone objecting can re-open or change to DECISIONNEEDED. That might, however, animate to close many feature requests on grounds of "I don't need that", even though it may have potentially many users. So maybe this kind of decision is better solved by a voting system?

Furthermore, if a feature request is severe enough (like changing existing API, adding another module, or changing a module from unsupported to supported), we should at least announce it on the mailing list and invite people to join the discussion on bugzilla/the pull-request page.

For the actual patches (or pull-requests) we will need some similar approach. Trivial patches can get accepted immediately, complex patches should better be reviewed at least once -- but either way we will need someone responsible for doing or delegating that.


Dipl.-Inf., Dipl.-Math. Christoph Hertzberg
Cartesium 0.049
Universität Bremen
Enrique-Schmidt-Straße 5
28359 Bremen

Tel: +49 (421) 218-64252

Mail converted by MHonArc 2.6.19+