To-do list for release 2013.02 about opm-core HOT 15 CLOSED

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.

• Build tutorials using CMake (issue #127)
• make check should run unit tests (issue #128)

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.