| Re: [eigen] Bugs on bugzilla |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen 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
pull-requests.
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.
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
----------------------------------------------