Comments (15)
How about having each 'thing' as separate issues, and then this as an 'index' which points to everything that remains? For instance, I can refer to the issues:
- Merge CMake branch with master (issue #119)
- Compute (extra) geometry properties for 2D grids (issue #121)
from opm-core.
Dune manages its releases this way using flyspray: you can define "depends on" relations for issues, thus having "tracker bugs" for releases. By coincidence there is also an OPM flyspray instance ;) at
http://opm-project.org/flyspray
(I'm in no way offended if it does not get used, though.)
from opm-core.
@atgeirr is the release numbered conventionally now (i.e. N.M)? I thought we went for YYYY.N. I'm just wondering, but I'm perfectly okay with both schemes...
from opm-core.
We did decide to go for YYYY.N and I think we should stick to this.
from opm-core.
I think issue #113 is a release blocker.
from opm-core.
@andlaus: I think the github issue tracker should be good enough (and is already in use), so that we do not need (a.t.m.) to use the flyspray. The biggest problem with github issue tracking is that all issues are associated with a single repo, but I think it is workable,
@kristinf: Yes, we decided YYYY.NN was the format for OPM as a whole, although I thought that version numbers for individual packages could be different. I no longer think that... I will try to change the name of the milestone.
from opm-core.
I agree, the issue tracker at github is working out quite well. My only concern on this now is that it may be difficult to migrate the history here to a new tracker should that be desirable (i.e., lock-in to github). However, I think we have other more important things to address at this point in time.
from opm-core.
On Mon, Jan 21, 2013 at 04:24:23AM -0800, Alf Birger Rustad wrote:
My only concern on this now is that it may be difficult to migrate
the history here to a new tracker should that be desirable (i.e.,
lock-in to github).
This lock-in kind of holds for other issue trackers, too. At DUNE we
are kind of locked in on flyspray. Migration would probably be
possible, but would still be a lot of work due to different database
layouts, etc.
from opm-core.
from opm-core.
OpenRS? This is not a big issue, but I see that many of the older files e.g. dune-cornerpoint/dune/grid/CpGrid.hpp contain reference to OpenRS. "This file is part of The Open Reservoir Simulator Project (OpenRS)". Should this be changed to OPM?
from opm-core.
All of this should change to OPM, yes.
from opm-core.
@alfbr Apparently others have considered migration of issues before: https://github.com/sorich87/github-to-bitbucket-issues-migration
from opm-core.
@kristinf: See PR #135, which removes all mention of OpenRS. Could you do the same for dune-cornerpoint etc.?
from opm-core.
I will do the same for dune-cornerpoint etc.
from opm-core.
As it turns out, this issue was not used for keeping track of the release process. I'll close it and think about how we can improve the release process for future releases.
from opm-core.
Related Issues (20)
- Some tests break after OPM/opm-parser#768 HOT 1
- Initialization and restart HOT 1
- Failing test_relpermdiagnostics HOT 4
- Dereferencing of end iterator happens in initStateEquil.hpp
- test_pinchprocessor is broken? HOT 3
- opm-core build fails HOT 4
- parameter's ouput does not show up in .CASE_NAME.DEBUG HOT 2
- Allow passing the size of the initial time step to adaptive time stepper HOT 1
- Runtime failure in "linsolver" test - umfpack not configured HOT 2
- Add restart test with no wells present.
- WellState::init has memory problems HOT 7
- Don't we need to keep track of (artificially) shut completions in the simulator for output? HOT 3
- Windows Installer (guide) failed HOT 3
- Compilation error due to not finding opm/output/data/Wells.hpp HOT 2
- Broken test HOT 3
- Multiple definitions of OPM_THROW HOT 1
- opm-core broken related to petsc HOT 2
- Some files missing? HOT 2
- Question: How OPM handles well sources in multi-cell wells? HOT 4
- Installing OPM in CentOS 8.1 (RPM) HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from opm-core.