To-do list for release 2013.02

[atgeirr]

This is an attempt to collect various things that must be done/fixed before we can do a release. Alternatively, we may post each separate thing as an issue, please state your opinion!

• Before branching: merging any code that should be in the release, renaming any classes or functions that are ill-named, restructuring the directory hierarchy if necessary.
• Branch the release (need to find a useful branch name, it will live forever). I would like to do this January 23rd (Wednesday), if possible.
• Ensure that the library builds with cmake on all relevant platforms.
• Build debian packages (issue Debian packaging #112).

[rolk]

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 Merge CMake branch with master #119)
• Compute (extra) geometry properties for 2D grids (issue Compute (extra) geometry properties for 2D grids #121)

[andlaus]

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.)

[andlaus]

@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...

[kristinf]

We did decide to go for YYYY.N and I think we should stick to this.

[bska]

I think issue #113 is a release blocker.

[atgeirr]

@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.

[alfbr]

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.

[blattms]

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.

[rolk]

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

[kristinf]

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?

[atgeirr]

All of this should change to OPM, yes.

[atgeirr]

@alfbr Apparently others have considered migration of issues before: https://github.com/sorich87/github-to-bitbucket-issues-migration

[atgeirr]

@kristinf: See PR #135, which removes all mention of OpenRS. Could you do the same for dune-cornerpoint etc.?

[kristinf]

I will do the same for dune-cornerpoint etc.

[atgeirr]

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.