On 09/05/14 06:37, Atgeirr Rasmussen wrote:
Hello,
In general issues for such as this I recommend using the issue tracker on
github, which
makes it easier to keep track of bugs and fixes. I have posted an issue:
https://github.com/OPM/dune-cornerpoint/issues/107
I suggest further discussion of this takes place there.
Hey,
GREAT link! Does each software module have it's own bug tracker, or is
this link the general bug_tracker for all software issues?
For example, I did find:
https://github.com/OPM/opm-parser/issues/285
This does seem to be a "user" question and not a specific bug issue?
Should feature requests go into the the bug filings, before a larger
group discusses the relative merits to a new feature?
What if somebody has a broader issue that is not specific to a code or
they cannot focus it down to a particular software component? What if an
issue/bug is related to several different components? I guess what I'm
asking is there an all encompassing bug tracker for OPM?
Do we have but one bug tracker for everything (OPM) or many?
Often for those less familiar, someone like yourself will guide the user
to file the appropriate bug report. After a while new folks learn the
(project) semantics and make good decisions accordingly.
On Gentoo, we have (2) most active discussion groups, where anything
relevant is "fair-game" for discussion. One is call Gentoo-dev, the
other is Gentoo-user, and it makes splitting the issues keenly accurate.
Perhaps (2) discussion groups: OPM-dev and OPM-user are appropriate
and a single (code specific) bug tracker? [1] That way all bugs and
inter-related bugs are easily tracked, research and the appropriate
section (module) maintainers can close out bugs according
to the OPM cultural semantics of the developers in responsible charge.
If not one "bugzilla" bug tracker, perhaps just one bug tracker for all
bugs, but categorized by the related module; perhaps at github? In my
experience, placing the bug tracker so close to the source download for
the nightly builds, is just asking for trouble, from an admin
perspective; ymmv.
Also, could you elaborate on the OPM semantics or point to a doc or
previous (archived?) posting on just how and when to post bugs and
when/where to post questions that may or may not be a bug, bug related
or such?
For me, the OPM project culture seems a bit "reserved" as compared to
many other open-source experiences. And if the semantics are:
Opm-project is opm-user, and the module bug trackers are to be module
specific, then where do the opm-developers discuss the codes and modules
and other issues that encompass issues greater than one
module? Private emails? IRC? Forums? Is OPM really open-source
and community driven, or are a few making the decisions quietly, and
publishing sources and providing binary downloads only? It just does
not seem to have much "community" which is the central point to all open
source, imho.
curiously,
James
[1] http://www.bugzilla.org/download/
[2] bugs.gentoo.org (for an excellent bug tracker system example).
Atgeirr
5. sep. 2014 kl. 12:47 skrev Jørgen Kvalsvik <[email protected]>:
On 2014-09-05 12:28, [email protected] wrote:
Hello Jørgen,
the DUNE_VERSION_NEWER macro needs the header
dune/common/version.hh
Maybe that is missing.
Best,
Robert
I have the header installed. The problem is that the cmake modules has a "feature
test" by compiling a trivial C++ program that includes a header from a dependency,
in this case dune-cornerpoint. It isn't the macro that's missing, it's the actual version
number it seems.
Interestingly, by explicitly including dune/control/version.hh the test still
fails.
_______________________________________________
Opm mailing list
[email protected]
http://www.opm-project.org/mailman/listinfo/opm
_______________________________________________
Opm mailing list
[email protected]
http://www.opm-project.org/mailman/listinfo/opm
_______________________________________________
Opm mailing list
[email protected]
http://www.opm-project.org/mailman/listinfo/opm
